createNamespace: false is ignored when committing a release
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 72/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- typescript
- Área
- backend
Línea de trabajo
Read beginReleasePublishLocked and commitReleasePublishLocked in packages/dynamic-apps/src/actors.ts to trace how createNamespace flows through preparation and commit. Then find the publication tests and add a regression covering a complete publish with createNamespace: false. It is done when that publish succeeds without attempting namespace creation.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
deployApp({ createNamespace: false, ... }) still attempts namespace provisioning when committing a release. This reproduces with a plain Fetch-handler app that does not import or depend on RivetKit.
The Deploy documentation says false disables namespace provisioning entirely. The preparation path honors the flag, but the commit path calls provisionAppNamespace() unconditionally.
Environment
@rivet-dev/dynamic-apps: 0.3.2, unmodified npm release@rivet-dev/[email protected],@rivet-dev/[email protected],[email protected](the package's dependencies; no overrides)- Self-hosted
rivetdev/engine:3.0.0-preview.4 - Node.js 26.13.0, Linux x64
Minimal reproduction
Use the disposable Compose setup and dependency installation in https://github.com/rivet-dev/dynamic-apps/issues/305. It supplies a fresh host namespace/pool and a serverful runner connected to Engine by its Docker hostname.
The complete deploy.ts used there is:
import { randomUUID } from "node:crypto";
import { deployApp } from "@rivet-dev/dynamic-apps";
const appId = `example-${randomUUID()}`;
const createNamespace = process.env.CREATE_NAMESPACE !== "false";
try {
await deployApp({
appId,
createNamespace,
files: {
"package.json": JSON.stringify({ name: "example", private: true, type: "module", main: "index.js" }),
"index.js": 'export default { fetch() { return new Response("hello"); } };',
},
});
console.log("Deployment succeeded", { createNamespace });
process.exit(0);
} catch (error) {
console.error("Deployment failed", { createNamespace, message: error.message, code: error.code });
process.exit(1);
}
Run with namespace creation explicitly disabled:
docker compose run --rm -e CREATE_NAMESPACE=false runner
The randomly generated app ID ensures this exercises a fresh application rather than an existing namespace.
Expected
The valid app deploys without calling namespace provisioning. The host's existing namespace is available; the generated app has no RivetKit dependency and needs no separate namespace.
Actual
The build succeeds, then deployment attempts namespace creation and fails:
Deployment failed {
createNamespace: false,
message: 'Rivet namespace creation failed with HTTP 422',
code: 'dynamic_apps_namespace_create_failed'
}
Engine 3 rejects display_name in that attempted request, as detailed in https://github.com/rivet-dev/dynamic-apps/issues/305. That payload incompatibility is separate: even if the endpoint accepted the request, attempting provisioning here would still contradict createNamespace: false.
Code path
beginReleasePublishLockedselectsunprovisionedAppNamespace()wheninput.createNamespace === false.commitReleasePublishLockedcallsprovisionAppNamespace()unconditionally.
The namespace-provisioning choice needs to survive the prepare/upload/commit sequence. A regression test should exercise the complete publication, not just the initial preparation, and assert that no namespace creation is attempted with the flag disabled.
- Lenguaje dominante
- TypeScript
- Estrellas
- 1k
- Forks
- 53
- Merge medio
- 2 h 54 min
- PR fusionados (30 d)
- 5
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Sin guía de contribución
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 rivet-dev/dynamic-apps
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
rivet-dev/dynamic-apps#305 ·
-
Build cache ignores maxResponseBytes, potentially reusing an outdated response limitPosiblemente ocupada @Utkarshpandey0001 la tomó hace 46 días. Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 78/100
rivet-dev/dynamic-apps#297 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 58/100
rivet-dev/dynamic-apps#280 · 2 comentarios ·
-
Make agentOS runtime classifier content-based (match Linux exec semantics), not extension-basedPosiblemente ocupada @mittal-parth la tomó hace 51 días. Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
rivet-dev/dynamic-apps#275 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 55/100
rivet-dev/dynamic-apps#272 ·
Todos los issues de rivet-dev/dynamic-apps
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Open-Earth-Foundation/CityCatalyst#3399 ·
Los mantenedores suelen responder en 2 días
-
userReport
Dificultad 1/5 Menos de una hora Aptitud para principiantes 72/100
nkprasad12/morcus-net#631 ·
Los mantenedores suelen responder en 1 día
-
fix(app): fail closed if GetGeneralSetting fails during initializationPosiblemente ocupada @kalavt la tomó hoy. Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
nekko-labs/nekko-agent#1756 ·
Los mantenedores suelen responder en 1 día
-
needs-area-label
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 2 días