Follow-up F7 from the product-version selector discussion. This issue tracks implementation work; the decision to keep host/serviceId/envTag lookup does not complete it.
Coordinating owner: @stevehu — Java DCL adoption/cache/reload-policy coordination.
Scope and acceptance criteria
Keep broad fallback-policy changes separately scoped from the selector decision.
Define release-scoped cache ownership and file inventories, failure propagation,
and transactional adoption if a whole-bundle guarantee is required. Pinning HTTP
requests alone does not make writes atomic or remove obsolete files.
Fail fast when required remote values cannot be obtained and no policy-approved,
compatible cache exists, whether or not the target directory exists. Do not
infer cache presence from the directory or emit a cache-source success claim
without verifying the cache. Define explicit outcomes for unusable/empty values
and partial bundle failures. The runbook rejects fallback for pipeline-controlled
release starts, not all subsequent automatic restarts. Enforce that gate in the
release workflow rather than permanently deleting caches on each boot. Any
broader change to normal-runtime fallback policy requires compatibility approval.
Acceptance must cover:
- Absent directory, existing directory without
values.yml, approved cache,
and incompatible/stale cache, crossed with HTTP >=300 (including no-current
snapshot 404), connection/connect-timeout failure, and empty/unusable values.
No-cache failure must not silently continue in either directory state.
- A successful values fetch followed by separate cert/file failures. Failed
empty-map responses must not be accepted as valid empty inventories or silently
reuse stale assets. Coordinate endpoint-specific diagnostics and outcome state
with F3; no complete-bundle success claim after a partial failure.
- Values/file write failures, partial-start retries, obsolete files on volume
reuse, and concurrent reload. Do not remove independent local credentials or
bootstrap files. Decide whether reload updates the whole bundle or explicitly
requires restart for cert/file changes.
- Release-start gates versus verified-release steady-state restarts: applying
the pipeline gate must not silently disable the existing cache fallback for
later liveness restarts, evictions, or scale-out.
Coordinate failure-state ownership with F3; transport pinning and safe provenance belong there, while adoption/cache/reload semantics belong here.
Implementation area and related history
server/src/main/java/com/networknt/server/DefaultConfigLoader.java, config-reload/src/main/java/com/networknt/config/reload/handler/ConfigReloadHandler.java, and loader/reload tests. Preserve the compatibility intent of #2181; #2752 source logging is not proof of successful bundle adoption.
Design reference
Product Upgrade Runtime Contract (publication accompanies the approved documentation change). F identifiers refer to the sections of that design. The related work below is tracked separately; these links are coordination references, not a claim that every item blocks this issue.
Related implementation issues
Follow-up F7 from the product-version selector discussion. This issue tracks implementation work; the decision to keep host/serviceId/envTag lookup does not complete it.
Coordinating owner: @stevehu — Java DCL adoption/cache/reload-policy coordination.
Scope and acceptance criteria
Keep broad fallback-policy changes separately scoped from the selector decision.
Define release-scoped cache ownership and file inventories, failure propagation,
and transactional adoption if a whole-bundle guarantee is required. Pinning HTTP
requests alone does not make writes atomic or remove obsolete files.
Fail fast when required remote values cannot be obtained and no policy-approved,
compatible cache exists, whether or not the target directory exists. Do not
infer cache presence from the directory or emit a cache-source success claim
without verifying the cache. Define explicit outcomes for unusable/empty values
and partial bundle failures. The runbook rejects fallback for pipeline-controlled
release starts, not all subsequent automatic restarts. Enforce that gate in the
release workflow rather than permanently deleting caches on each boot. Any
broader change to normal-runtime fallback policy requires compatibility approval.
Acceptance must cover:
values.yml, approved cache,and incompatible/stale cache, crossed with HTTP >=300 (including no-current
snapshot 404), connection/connect-timeout failure, and empty/unusable values.
No-cache failure must not silently continue in either directory state.
empty-map responses must not be accepted as valid empty inventories or silently
reuse stale assets. Coordinate endpoint-specific diagnostics and outcome state
with F3; no complete-bundle success claim after a partial failure.
reuse, and concurrent reload. Do not remove independent local credentials or
bootstrap files. Decide whether reload updates the whole bundle or explicitly
requires restart for cert/file changes.
the pipeline gate must not silently disable the existing cache fallback for
later liveness restarts, evictions, or scale-out.
Coordinate failure-state ownership with F3; transport pinning and safe provenance belong there, while adoption/cache/reload semantics belong here.
Implementation area and related history
server/src/main/java/com/networknt/server/DefaultConfigLoader.java,config-reload/src/main/java/com/networknt/config/reload/handler/ConfigReloadHandler.java, and loader/reload tests. Preserve the compatibility intent of #2181; #2752 source logging is not proof of successful bundle adoption.Design reference
Product Upgrade Runtime Contract (publication accompanies the approved documentation change). F identifiers refer to the sections of that design. The related work below is tracked separately; these links are coordination references, not a claim that every item blocks this issue.
Related implementation issues