Pnpjs: @pnp/sp/items Unable to batch add item in list .

[waqarjavaid25]

Following code is not working.following are configration

"@pnp/common": "^1.2.8",
"@pnp/logging": "^1.2.8",
"@pnp/nodejs": "^1.2.8",
"@pnp/odata": "^1.2.8",
"@pnp/sp": "^1.2.8",

Following code never run after line

        **console.log("batch", batch);**

out put of batch variable is:

batch SPBatch {_batchId: "8f8c60c0-da90-4ea1-bffe-34338312cc0c", _reqs: Array(0), _deps: Array(0), _rDeps: Array(0), baseUrl: ""}baseUrl: ""batchId: (...)requests: (...)_batchId: "8f8c60c0-da90-4ea1-bffe-34338312cc0c"_deps: Array(6)0: Promise {}1: Promise {: undefined}2: Promise {}3: Promise {: undefined}4: Promise {: undefined}5: Promise__proto__: Promise[[PromiseStatus]]: "resolved"[[PromiseValue]]: undefinedlength: 6__proto__: Array(0)_rDeps: Array(2)0: Promise {}1: Promise__proto__: Promise[[PromiseStatus]]: "pending"[[PromiseValue]]: undefinedlength: 2__proto__: Array(0)_reqs: Array(2)0: {id: "6425330f-385f-4533-bcc3-1fd9eff41ba3", method: "POST", options: {…}, parser: ODataDefaultParser, reject: ƒ, …}1: {id: "c8b702d6-ebe0-4d28-8ea9-4f59b30720a2", method: "POST", options: {…}, parser: ODataDefaultParser, reject: ƒ, …}length: 2__proto__: Array(0)__proto__: ODataBatch

if there is some error it should show in catch method,but no error catched,

  let list = sp.web.lists.getByTitle("Recommendations");
        console.log("list", list);
        list
          .getListItemEntityTypeFullName()
          .then(entityTypeFullName => {
            console.log("entityTypeFullName", entityTypeFullName);
            let batch = sp.web.createBatch();
            console.log("batch", batch);
            list.items
              .inBatch(batch)
              .add({ Title: "Batch 6" }, entityTypeFullName)
              .then(b => {
                console.log("Batch 6", b);
              })
              .catch(e => {
                console.log("Batch 6", e);
              });

            list.items
              .inBatch(batch)
              .add({ Title: "Batch 7" }, entityTypeFullName)
              .then(b => {
                console.log("Batch 7", b);
              })
              .catch(e => {
                console.log("Batch 7", e);
              });

            batch
              .execute()
              .then(d => console.log("Done", d))
              .catch(e => console.log(e));
          })
          .catch(e => {
            console.log("error", e);
          });

[koltyakov]

Hi @waqarjavaid25,

Can you provide some more details?

• Version of SharePoint
• The browser
• Were polyfills used?

[waqarjavaid25]

hi @koltyakov

• SharePoint online is being used.
• Chrome version (71.0.3578.98) is being used
• polyfills are not being used.

[koltyakov]

Confirming, in v1.2.8 something was introduced which breaks the scenario.

Tested using a bit modified sample:

// <script src="https://cdnjs.cloudflare.com/ajax/libs/pnp-pnpjs/1.2.8/pnpjs.es5.umd.bundle.min.js"></script>
var sp = pnp.sp;

(async () => {

  const list = sp.web.lists.getByTitle('Custom');
  const ent = await list.getListItemEntityTypeFullName();

  const batch = pnp.sp.web.createBatch();
  const items = list.items.inBatch(batch);

  items.add({ Title: 'Item 1' }, ent).catch(console.warn);
  items.add({ Title: 'Item 2' }, ent).catch(console.warn);

  await batch.execute();
  console.log('Done');

})()
  .catch(console.warn);

This ends up with never resolved promises.
When switching to v1.2.7, the code works as expected.

[patrick-rodgers]

The issue here is that we made some changes to how batches are setup, namely that when you call inBatch we create at that moment a dependency to block resolution of the batch. This gives us the ability to ensure we get the requests added to the batch BEFORE the batch executes regardless of how the engine chooses to process the requests. I.e. we are time independent. So why this error? Well, in the add method we actually end up with 3 batch dependencies for each request (by design, but)

1. The first request is added on the FIRST inBatch call (i.e. the call in the written code)
2. Internally to the method we create another dependency since we are doing multiple calls and we need to ensure things are added to the batch in order
3. ANOTHER dependency is created when the object is cloned internally to the add method

It is the dependency in 1 that is not being resolved, which ends up blocking the request. Working on the best way to fix this, but that is at least what is happening.

[martin-braun]

The issue here is that we made some changes to how batches are setup, namely that when you call inBatch we create at that moment a dependency to block resolution of the batch.

The batch mechanism was changed without running batched CRUD tests before release?

[patrick-rodgers]

I get you are having a go at us because it is the internet and it is fun to and it feels good - well done.

The answer is we had a testing gap and didn't have coverage for this case. We added a test to ensure we catch it next time. The best we can do is improve when we find an issue as we did here. Thanks as always for the feedback.

[nero120]

@patrick-rodgers he's not "having a go" at you, it's a very valid point and was the first reaction I had as well. Everyone appreciates the effort you put in to this library but when something like this happens users will inevitably wonder how it slipped through testing, which your answer clarifies.

[martin-braun]

I get you are having a go at us because it is the internet and it is fun to and it feels good - well done.

I'm sorry that you feel this way, it was meant to be constructive criticism with positive intention. I'm glad for the time and work you put into this, but it loses some of its value when official documented code does not work. It just causes people to search for issues in their own code and cost time on their end, like it did at me, until they stomp over this.

The answer is we had a testing gap and didn't have coverage for this case. We added a test to ensure we catch it next time. The best we can do is improve when we find an issue as we did here. Thanks as always for the feedback.

Thank you, I'm glad actions has been taken, immediately. Looking forward for the improved batching in 1.2.9.