Skip to content

👷(CLDSRV-860) Monitor async await migration#6088

Open
DarkIsDude wants to merge 8 commits intodevelopment/9.3from
feature/CLDSRV-860/monitor-async-await-migration
Open

👷(CLDSRV-860) Monitor async await migration#6088
DarkIsDude wants to merge 8 commits intodevelopment/9.3from
feature/CLDSRV-860/monitor-async-await-migration

Conversation

@DarkIsDude
Copy link
Contributor

@DarkIsDude DarkIsDude commented Feb 25, 2026

@DarkIsDude DarkIsDude self-assigned this Feb 25, 2026
@bert-e

This comment was marked as resolved.

@bert-e

This comment was marked as resolved.

@DarkIsDude DarkIsDude changed the base branch from development/9.2 to development/9.3 February 25, 2026 15:48
@bert-e

This comment was marked as resolved.

@codecov

This comment was marked as resolved.

@DarkIsDude DarkIsDude marked this pull request as ready for review March 10, 2026 16:09
@DarkIsDude DarkIsDude requested review from a team, benzekrimaha and delthas March 10, 2026 16:09
@DarkIsDude DarkIsDude force-pushed the feature/CLDSRV-860/monitor-async-await-migration branch from 93020af to 8981239 Compare March 10, 2026 16:10
@claude

This comment was marked as resolved.


if (process.env.GITHUB_STEP_SUMMARY) {
const { writeFileSync, appendFileSync } = await import('node:fs');
appendFileSync(process.env.GITHUB_STEP_SUMMARY, [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we really want a summary in every PR?
for monitoring the progress, this may be done in a separate job (eg. nightly on on dev branches) which builds a report giving the status on the "latest branch" (as a badge in the README, as a GitHub page, ....)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO we can keep it simple as compute the report in each PR. Not a big deal, it's only some seconds so no finance impact.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was not thinking about build time or finance, but really about relevance:

  • a summary is "inside" the build, so people will not go look at it - not will it show them how much progress they made (in their PR)
  • for "monitoring", i.e. if someone want to (periodically...) check the status : not sure it is very practical to just go and look inside the last finished build

the summary does not hurt I agree, but I'd rather have something more dedicated to their purpose, like

  • a report in a "static" place : GitHub page, badge in the Readme, periodic reporting job...
  • a comment on the PR indicating how this specific PR affected the async migration (like "Great, you removed 10 async calls! Migration is now 53% complete, keep pushing!")

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point 🙏. Let's start simple again and I'll add your comment. We don't know how this will be use and what is needed from the team/dev. So I suggest to not waste time on that and iterate when we have feedback ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't know how this will be use and what is needed from the team/dev

That is not really true : this work was started because you wanted to solve a problem, i.e. gaining visibility on progress of the migration I think.
And my point here is really simple : does the summary approach give you that visibility?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should these scripts not be in the Guidelines repo, so they can be reused?

(and if needed, it may include a github action as well)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now as it's the first repo, I would keep them here. When will be migrated to an another repo, can be. Maybe with a claude skills also 🤷

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now as it's the first repo, I would keep them here

why do you say that?
Do we expect to have to iterate on these scripts, and need "closeness" with the code? Or do you think the script are kind of tailored to cloudserver, and would not work as such in other code base?

@bert-e

This comment was marked as resolved.

@bert-e

This comment was marked as resolved.

@bert-e

This comment was marked as resolved.

@DarkIsDude DarkIsDude force-pushed the feature/CLDSRV-860/monitor-async-await-migration branch from a64c535 to f1e7018 Compare March 19, 2026 13:23
@claude

This comment was marked as resolved.

@claude

This comment was marked as resolved.

@DarkIsDude DarkIsDude force-pushed the feature/CLDSRV-860/monitor-async-await-migration branch from f1e7018 to c4d81e1 Compare March 19, 2026 13:26
@claude

This comment was marked as resolved.

@claude

This comment was marked as resolved.

@DarkIsDude DarkIsDude force-pushed the feature/CLDSRV-860/monitor-async-await-migration branch from f3ff7ea to 8612e12 Compare March 19, 2026 16:35
@claude

This comment was marked as resolved.

if (fn.isAsync()) continue;

const startLine = fn.getStartLineNumber();
if (!addedLines.has(startLine)) continue;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this the right filter?
This would consider only functions whose "header" is changed : and skip if only an update is made inside the existing function's body...

should we not search that there are no addedLines between fn.getStartLineNumber() and fn.getEndLineNumber() (or however it is called)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good comment that I didn't notice. Anyway I suggest to keep current behaviour. We can start "slowly" and not too aggressive. This will allow dev to be familiar with async/await and introduce not too much change at the start. I'll add a comment in the guideline to setup your suggestion in some months ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand the iterative approach, but I think it would be really too limited to only require await migrations on signature changes -- they change very rarely, not sure signature only is significant enough for a first iteration.

Copy link
Contributor

@delthas delthas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM on the whole (agree we can iterate later)

console.log(`Total functions: ${totalFunctions}`);
console.log(`Async functions: ${asyncFunctions} (${asyncFunctionPercent}%)`);
console.log(`Callback functions: ${callbackFunctions}`);
console.log(`Remaining .then(): ${thenChains}`);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we also count "dual-style" functions (async + cb)?


if (process.env.GITHUB_STEP_SUMMARY) {
const { writeFileSync, appendFileSync } = await import('node:fs');
appendFileSync(process.env.GITHUB_STEP_SUMMARY, [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't know how this will be use and what is needed from the team/dev

That is not really true : this work was started because you wanted to solve a problem, i.e. gaining visibility on progress of the migration I think.
And my point here is really simple : does the summary approach give you that visibility?

run: yarn run --silent lint -- --max-warnings 0
- name: Lint Javascript (strict, excluding async migration rules)
run: |
yarn run --silent lint -- --max-warnings 0 --rule "promise/prefer-await-to-then: off" --rule "n/callback-return: off"
Copy link
Contributor

@francoisferrand francoisferrand Mar 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should these rule exceptions not be added in the package.json instead?
so that developer can run yarn lint locally as well...

or do we expect developers to run lint with this rule, and be smart about ignoring them?

Comment on lines +74 to +75
"promise/prefer-await-to-then": "warn",
"n/callback-return": "warn",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • kind of redundant with the dedicated linter you added
  • in CI : disabled
  • in dev : since we migrate "function by function", there will probably be lots of warnings there... which may make the lint practically useless (too hard to use, too many warnings to ignore) for devs?

i.e. should we really add these now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants