Telegram (ask questions / claim the issue here first): https://t.me/+DOylgFv1jyJlNzM0
Labels: enhancement, backend, Stellar Wave, devops
Only HTTP requests get a correlation id, so worker logs from one poll cycle have nothing tying them together.
logger.ts:4-18 pulls requestId into log lines from the AsyncLocalStorage store that's set on HTTP requests. The Soroban worker and indexerService run outside any requestContext, so a poll batch and its per-event error logs carry no shared id. When something fails you can't tell which logs belong to the same poll cycle or a particular admin replay.
What the fix has to hold to
- all logs from one poll/replay cycle share a single id
- the id is available on error logs and handed back from the replay endpoint
Done when
Where to start
backend/src/workers/soroban-event-worker.ts and backend/src/services/indexerService.ts for wrapping the batches, backend/src/logger.ts for the field. Swapping the log transport/format library is out of scope. Small change, reuses the existing AsyncLocalStorage plumbing.
Labels:
enhancement,backend,Stellar Wave,devopsOnly HTTP requests get a correlation id, so worker logs from one poll cycle have nothing tying them together.
logger.ts:4-18pulls requestId into log lines from the AsyncLocalStorage store that's set on HTTP requests. The Soroban worker and indexerService run outside any requestContext, so a poll batch and its per-event error logs carry no shared id. When something fails you can't tell which logs belong to the same poll cycle or a particular admin replay.What the fix has to hold to
Done when
requestContext.run({ requestId: <batchId> }, ...)so its logs share an idWhere to start
backend/src/workers/soroban-event-worker.tsandbackend/src/services/indexerService.tsfor wrapping the batches,backend/src/logger.tsfor the field. Swapping the log transport/format library is out of scope. Small change, reuses the existing AsyncLocalStorage plumbing.