Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Refactor doc generation processes to eliminate exponential backoff in step functions

Aperta
  • Qualcosa non va?
#435 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
aws, typescript
Ambito
backend, cloud

Direzione di ricerca

Inizia da src/backend/orchestration/index.ts, in corrispondenza della configurazione collegata di exponential backoff, quindi leggi l’esempio di callback-task di AWS Step Functions a cui fa riferimento l’issue. Il lavoro è completato quando l’orchestrazione non dipende più da ripetuti errori di invocazione di ECS e supporta invece il lavoro accodato, l’avvio dei task consapevole della capacità, le risposte di callback e un percorso di errore di sei ore verso la DLQ.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

effort/large risk/medium stability

Background

When the doc generation process has issues, it's possible for its DLQ to get very large. (For example, in the Gamma account the DLQ currently has 20,000+ messages). When a Lambda is invoked to redrive these messages, it simply initializes thousands of step function executions, which delegate ECS tasks for generating documentation for individual languages. Since this spike of workload is far greater than what ECS can handle at once, the step function frequently gets throttled, so it has been configured with a very slow but exponential backoff:

https://github.com/cdklabs/construct-hub/blob/02d5ff3a01768b9203ac061be7ed90200f714e92/src/backend/orchestration/index.ts#L40

Problem

This backoff-and-retry solution causes the history of individual executions gets cluttered with dozens of failed ECS task requests, and moreover, the larger the number of concurrent tasks that are being executed, the longer it will take for the state machine executions to reach a point in time where individual tasks make progress.

Proposed solution

We can make this architecture more stable by introducing a queue, and a lambda function that polls from the queue and starts tasks whenever we are not close to hitting the task limit (e.g. below 80% capacity). In the state machine that spawns the individual tasks, instead of invoking the ECS task directly, it will add the tasks to an SQS queue, and then wait to receive a response before continuing the state machine, in accordance with the pattern described here: https://docs.aws.amazon.com/step-functions/latest/dg/callback-task-sample-sqs.html We can assume if the task execution does not hear a response for at least 6 hours, then it has failed and should go into the DLQ.

This would eliminate all errors caused by trying to invoke too many ECS tasks at once, while also giving us greater flexibility over how much compute we should allocate to the ECS cluster (we could likely set up autoscaling based on the amount of items in the queue).

Open Questions

The proposed solution is a somewhat common serverless architecture pattern - is there an existing CDK L3 construct we can use to abstract this behavior? If not, could we create one?

Lingua principale
TypeScript
Stelle
239
Fork
30
Merge medio
11h 4m
PR unite (30g)
15

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di cdklabs/construct-hub

Tutte le issue di cdklabs/construct-hub

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.