fix(device): reload stale persistent resolved-device entries - #8
Open
xylophonez wants to merge 1 commit into
Open
xylophonez wants to merge 1 commit into
xylophonez wants to merge 1 commit into
Conversation
A persistent loaded-device-store keeps device-reference -> module-atom entries across VM restarts, but a fresh VM lacks both the generated atom and its BEAM code. The cache-hit path's hb_util:atom/1 then raises badarg (or returns a module whose code is absent), which can stop a restarted node from serving HTTP when a device is used from on.start. Demote absent-atom / not-loaded entries to a cache miss via a guarded loaded_cached_module/1 helper so the maybe block falls through to trusted archive resolution. Adds a regression test.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
hb_device_loadcachesdevice reference -> generated module atomin the configuredloaded-device-store. The default for that store is volatile, but the option accepts ordinary store backends and can be configured as LMDB (or another persistent store) — which is desirable on nodes that want resolved dynamic devices to survive restarts.After the first VM resolves a dynamic device, a persistent store holds a binary such as
_hb_device_<archive-derived-name>. A fresh Erlang VM has neither that generated atom nor its loaded BEAM code. The current cache-hit path callshb_util:atom/1(existing-atom conversion), which raisesbadarg; and even if the atom happens to exist, returning it when its code is not loaded is not a usable cache hit either. A device used fromon.startcan therefore prevent the restarted node from serving HTTP at all.Reproduction
loaded-device-storeas an LMDB (persistent) store.<reference>entry is written.Observed:
list_to_existing_atomraisesbadarg, surfaced as a failed device resolution / node start. Expected: an entry whose atom or code is absent in this VM is treated as a cache miss, followed by normal trusted-archive resolution and loading.Fix
Replace the direct
hb_util:atom(Bin)match inget_resolved_device/2with a guarded helper that demotes "name not an existing atom" or "module not loaded" to a cache miss ({error, not_found}), so the surroundingmaybeblock falls through to the trusted archive path. Fail-safe direction: a stale entry is re-fetched and re-verified, never blindly trusted.Includes a unit test asserting that a loaded module round-trips and that
_hb_device_stale_cache_entry_that_is_not_an_existing_atomreturns{error, not_found}without adding an atom.Single file, no behavioural change for the default volatile store.