Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Preflight all externalized payload sizes before starting uploads

Abierto
  • ¿Algo no está bien?
#170 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
54/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go
Área
backend, testing

Línea de trabajo

Read internal/largepayload/bounded.go and internal/largepayload/codec.go, then inspect the existing tests under internal/largepayload. Add a message-wide size-validation pass before storage operations begin, preserving the stated concurrency and cancellation behavior. Verify orchestration and entity batch cases, including valid fields before an oversized field, UTF-8 boundaries, all-valid messages, and cancellation; done means deterministic size failures make zero storage calls and leave original fields unchanged.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug

Outgoing payload transformations collect a plan, but the plan does not validate all payload sizes before dispatching storage operations. MaxPayloadBytes is checked inside each operation. A deterministically oversized later field can therefore be rejected only after valid earlier fields have already created stored payloads.

Current source evidence

Inspected current main at c713409eb9a4295884169c144df9221f9a42aef6.

  • TransformOrchestratorResponse adds custom status and action fields to a transformation plan.
  • transformPlan.add and run snapshot a field and queue a closure that calls the transform inside runBounded; they do not perform a message-wide size-validation pass.
  • Externalize checks the current raw payload maximum and then calls StoreToken or Store.
  • The worker abandons the orchestration work item if transformation fails. Earlier successful storage operations are not rolled back or registered with the backend by that abandonment.

Requested regression

Add a source-level regression to the existing internal/largepayload tests using a counting in-memory store/resolver, actual protobuf types and TransformOrchestratorResponse:

  1. Configure ThresholdBytes: 8 and MaxPayloadBytes: 32.
  2. Create a response with a valid 16-byte custom status, eight valid 20-byte ScheduleTask.Input fields, and a final 33-byte ScheduleTask.Input.
  3. Record store calls and original response field values before calling the real transform.
  4. Expect errors.Is(err, api.ErrLargePayloadTooLarge), zero Store/StoreToken calls, and unchanged original fields.

The response intentionally contains more fields than the eight-operation concurrency cap. With the current scheduler, a valid operation must complete and release a slot before the late oversized operation is reached, exposing the avoidable earlier storage write without relying on the relative start order of two goroutines. Repeat for TransformEntityBatchResult.

Evidence boundary: the current code establishes the missing message-wide preflight. The proposed Go regression has not been executed for this filing; the equivalent JavaScript case was reproduced and fixed.

Acceptance Criteria

  • Validate all relevant raw payload sizes in an outgoing transformation plan before starting any storage operation.
  • A deterministic maximum-size violation produces zero storage calls and leaves original payload fields unchanged.
  • Preserve current Go size-validation scope, provider-specific inclusive threshold policy, defaults and option normalization.
  • Preserve native-token and wrapped-reference idempotency, field deduplication, and snapshot-based transformation.
  • Once validation succeeds, retain bounded concurrency, cooperative cancellation, draining of dispatched operations and message-order I/O failure selection.
  • Preserve no-op/missing-configuration behavior and do not change hydration semantics as an unrelated part of this repair.
  • Add valid-first/oversized-later orchestration/entity cases, UTF-8 boundaries, all-valid messages and cancellation coverage.
  • Document that deterministic invalid size is found before hypothetical earlier storage I/O failures.

Non-goals

This is not a cross-store transaction or a generic orphan collector. Real I/O/cancellation/uncertain-submission failures can still leave stored data. Do not unconditionally delete earlier uploads after an uncertain completion outcome: the backend may already have accepted a reference.

Carryover history is already explicitly traversed, and TestTransformContinueAsNewCarryoverEvents covers a large event. The JavaScript carryover field omission does not need a separate Go issue.

Related

Lenguaje dominante
Go
Estrellas
312
Forks
68
Merge medio
1 d 5 h
PR fusionados (30 d)
7

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoft/durabletask-go

Todos los issues de microsoft/durabletask-go

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.