Support for stream forking (Stream-Forked-From / Stream-Fork-Offset) per the Durable Streams protocol
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 45/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Stack tecnológico
- typescript
Línea de trabajo
Start by reading FEATURES.md and docs/durable-streams-spec.md, then compare the PUT /v1/stream/{name} behavior with the Durable Streams fork section and its Stream-Forked-From and Stream-Fork-Offset headers. Done means new streams inherit data through the requested offset, source deletion remains readable through active forks, direct source access returns 410 Gone, and garbage collection waits for the last fork.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
The base Durable Streams protocol defines stream forking via PUT with Stream-Forked-From and Stream-Fork-Offset headers (copy-on-write, refcounted soft-delete on the source when forks are still active). This server doesn't implement it, and it isn't listed as a known gap anywhere I could find â not in FEATURES.md, and the vendored docs/durable-streams-spec.md doesn't include the fork section at all (its own §4.2 is "List streams").
Use case: we run per-conversation durable streams for a chat agent (StreamDB/state-protocol on top of prisma/streams). When a user edits an earlier message or regenerates a reply, the natural model is a branch: fork the conversation stream at the edited turn's offset, keep the original branch addressable, and let the new branch diverge. Without server-side fork support, we're limited to destructive supersede (delete-and-rewrite rows in place), which loses the ability to keep multiple branches alive or let a user switch back to an earlier one.
Proposed behavior (matching the protocol spec):
- PUT /v1/stream/{name} with Stream-Forked-From: and Stream-Fork-Offset: creates a new stream that inherits all data from the source up to that offset.
- Source and fork may implement inheritance via copy-on-write or pointer-stitching â implementation detail, not prescribed by the protocol.
- Deleting a stream with active forks soft-deletes it (410 Gone to direct access) while forks can still read the inherited range; GC once the last referencing fork is deleted.
Alternatives considered: row-level supersede (what we do today) â works, but is destructive and can't represent multiple live branches of the same conversation, which is the actual UX we're after.
Happy to help test against a real implementation, or contribute if there's appetite for a PR â wanted to check whether this is a deliberate scope exclusion before writing one.
- Lenguaje dominante
- Rust
- Estrellas
- 8
- Forks
- 2
- Métricas de merge de PR
- Sin PR fusionados en 30 d
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
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de prisma/streams
Todos los issues de prisma/streams
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
riverqueue/river#1576 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
stadelmanma/fitparse-rs#64 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 4 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día