Storyblok CLI - Migrations - post-run report

[edvinasjurele]

I used v4.6.2 and ran storyblok migrations run badge --space {SPACE_ID} --verbose --publish published against space which has 302 pages using badge component.

I got the summary at the end.

As a user I am puzzled by 47 stories failed. It is quite unclear to me what happened there.

1. Why they were failing?
2. Which stories were failing?
3. How should I solve this to make all pass? Retry whole migration once again, causing ALL stories to be fetched again regardless? Possible to run failed ones only?

As an idea, I would add some .storyblok/migrations/{SPACE}/reports/run-1753693941599.json and then at least have some report to address things manually.

[edvinasjurele]

I did the re-run just right after expecting that I will update 47 stories which were not touched. Unfortunatelly, this puzzled me even more 🤯 it seems migrations were applied but just pushing failed (at least that is what summary shows), and the re-run simply made those not updated stories be skipped entirely? I checked CMS pages manually and it seems mostly all of them were after all updated successfully which does not match with information of 47 stories failed in summary.

[imranolas]

There was a bug that has since been resolved in the latest release https://github.com/storyblok/monoblok/releases/tag/storyblok%404.6.3

[edvinasjurele]

Hi, awesome, this fixed the count issue, which is discussed in #295 (comment), so I am refraining myself from creating a bug ticket 🙏

Though in regards to reporting and knowing what failed, I think this ongoing discussion is still valid. I used v4.6.3 and I still see some stories failed, and as a user it is super unclear why.

---

Some of cases are super clear - one story requires manual fixing due to some "required" validations not met correctly, which results in even Save not working, which I am sure CLI fails with Unprocessable content or similar error (at least that was the error in v3 before).

Other stories might have been rate limited maybe?

I might make some console logging to know exact reasons, but some reporting summary would be just awesome and wouldnt leave users in unknown.

[edvinasjurele]

I did really simple console logging in this function inside node_modules:

/**
   * Get a summary of the update results
   */
  getSummary() {
    const { successful, failed, totalProcessed } = this.results;
    if (totalProcessed === 0) {
      return `No stories required updates.`;
    }
    let summary = `Update Results: ${successful.length} stories updated`;
    console.log(failed);
    if (failed.length > 0) {
      const failedStoryIds = new Set(failed.map((result) => result.storyId));
      summary += `, ${failed.length} stories failed => storyIds: ${[...failedStoryIds].join(', ')}`;
    }
    summary += `.`;
    return summary;
  }

and got more information:

simple logging of failed story ids helps a lot for the time-being!

[maoberlehner]

@edvinasjurele, with release 4.8.0, we've added (and enabled by default) file logging, and with release 4.10.0 came reports. If you find the time, we'd be happy to hear from you if this covers all of your use cases.