Batching Messages on Initial Project Load

[LorisSigrist]

Context

As discussed with @martin.lysk1

Currently when a large project is loaded the project.query.messages.getAll gets triggered several times with intermediate message states instead of just the final message state.

This causes unnecessary code executions & caching issues in dependent Inlang Apps

Proposal

Batch messages & only trigger the getAll callback once all messages have been loaded.

[jldec]

@martin-lysk is this a side effect of the every-500-messages sleep during load? Would you mind taking a look to see if we should remove that? 🙏

b.t.w. I could not repro this with load-test Here's a run with 4000 messages and experimental persistence removed from the settings. The 2nd event was triggered by my edit and save of the messages file.

$ pnpm load-test 4000 0 1 1 1

> @inlang/sdk-load-test@ load-test /Users/jldec/opral/monorepo/inlang/source-code/sdk/load-test
> pnpm clean && MOCK_TRANSLATE_LOCAL=1 DEBUG=$DEBUG,load-test tsx ./main.ts "4000" "0" "1" "1" "1"

> @inlang/sdk-load-test@ clean /Users/jldec/opral/monorepo/inlang/source-code/sdk/load-test
> rm -rf ./locales ./project.inlang/messages.json

  load-test load-test start - watchMode on, ctrl C to exit +0ms
  load-test generating 4000 messages +0ms
  load-test opening repo and loading project +8ms
Using existing cloned repo
  load-test subscribing to project.errors +2s
  load-test subscribing to messages.getAll +0ms
  load-test messages getAll event: 1, length: 4000 +8ms
  load-test subscribing to lintReports.getAll +0ms
  load-test lint reports changed event: 1, length: 144000 +237ms
  load-test load-test done - watching for events +0ms
  load-test messages getAll event: 2, length: 4000 +50s

[jldec]

@martin.lysk, @loris.sigrist please confirm that you have a repro for the issue that this is intended to fix. Thanks

[martin-lysk]

As @jldec also checked - this is not the cause of the problem in initial load. We tackle this by batching in sub sequential loads MESDK-111

[jldec]

@martin-lysk does this mean that you can repro the issue by modifying messages after the first load? I tried to do this by manually editing messages in the file and saving it but that did not produce excess events either.

[LorisSigrist]

We don't have a reliable repro for the original issue, but we can repro the behavior where when making n edits at once you get n callbacks triggered instead of just one with the final state.

Even without the original issue batching would be desirable.

[jldec]

ok - that sounds like an API change similar to what we did for the lintreports `getAll()` api. I'll change the description of MESDK-111 accordingly.