Skip to content

fix(devnet): make NM processedPath a sibling of srcPath, not a child - #205

Open
mateeullahmalik wants to merge 1 commit into
masterfrom
matee/devnet-nm-processed-path-sibling
Open

fix(devnet): make NM processedPath a sibling of srcPath, not a child#205
mateeullahmalik wants to merge 1 commit into
masterfrom
matee/devnet-nm-processed-path-sibling

Conversation

@mateeullahmalik

Copy link
Copy Markdown
Contributor

Problem

e357c6e7 fixed the [scanner].directories block to emit correctly-typed inline tables (the crudini bug), but derived the destination as:

local processed="${dir%/}/processed"     # INSIDE the scanned directory

scanner/scanner.go walks srcPath with filepath.Walk — recursive — and dedups on (dir, name):

err := filepath.Walk(directory.SrcPath, func(path string, info os.FileInfo, err error) error {
    ...
    dir  := filepath.Dir(path)
    name := filepath.Base(path)
    exists, err := s.db.HasFile(dir, name)

So a nested <srcPath>/processed is re-scanned on the next tick. The move changed dir, so HasFile(dir, name) misses and the file looks brand new — it is registered a second time.

Cost: two cascade registrations per file (~15120ulume each, enforced at x/action/v1/keeper/action.go:69) plus double supernode upload load, silently.

Evidence

Observed on the shared devnet — create-metadata start whose source path is already under the processed dir:

INFO rq: create-metadata start {"path": "/shared/nm-files/processed/post-v1120-1786409328-304734.bin"}
INFO rq: create-metadata start {"path": "/shared/nm-files/processed/post-v1120-1786409353-304735.bin"}
INFO rq: create-metadata start {"path": "/shared/nm-files/processed/post-v1120-1786409378-304736.bin"}

13 such re-registrations before the fix.

Fix

Derive a sibling:

local processed="${dir%/}-processed"     # /shared/nm-files -> /shared/nm-files-processed

This restores the uploader's own convention — its shipped config.toml pairs ~/.lumera-uploader/drop with the sibling ~/.lumera-uploader/processed, never a child:

directories = [
  { srcPath = "~/.lumera-uploader/drop", processedPath = "~/.lumera-uploader/processed", isPublic = "random" }
]

Verification

Deployed to the shared devnet (5 validators, chain v1.20.2-rc1, SN v2.6.4-testnet), NM restarted through the normal start.sh path with no overrides:

metric before fix after fix
re-registrations sourced from processed dir 13 0
uploads started 210
processed_files 1242 1276

Generated config after the change:

directories = [
  { srcPath = "/shared/nm-files", processedPath = "/shared/nm-files-processed", isPublic = "random" },
  { srcPath = "/root/nm-files", processedPath = "/root/nm-files-processed", isPublic = "random" },
  { srcPath = "~/.lumera-uploader/drop", processedPath = "~/.lumera-uploader/drop-processed", isPublic = "random" }
]

Sustained over ~10 minutes of live load with zero re-registrations.

Risks

Low. Devnet tooling only — no chain code, no state machine, no consensus surface. bash -n clean. No other file in the repo references the nested path.

Rollback

Revert the commit; the previous behavior returns immediately on the next lumera-uploader-setup.sh run.

Operator note

On a devnet that already ran the nested version, move stranded files out of the scan path before restarting, or they get re-registered once on the next pass:

mv -f /shared/nm-files/processed/* /shared/nm-files-processed/
rmdir /shared/nm-files/processed

e357c6e fixed the scanner block to emit correctly-typed inline tables, but
derived the destination as "${dir%/}/processed" -- i.e. INSIDE the directory
being scanned.

scanner/scanner.go walks srcPath with filepath.Walk (recursive) and dedups on
(dir, name). A nested processed dir is therefore re-scanned on the next tick,
and because the move changed `dir` the DB lookup misses, so the file is
registered a SECOND time. Every upload costs two cascade registrations
(~15120ulume each) and double supernode load.

Observed on the shared devnet: 13 `create-metadata start` calls whose source
path was already under .../processed/.

Deriving the sibling "${dir%/}-processed" restores the uploader's own
convention -- its shipped config.toml pairs ~/.lumera-uploader/drop with the
sibling ~/.lumera-uploader/processed, never a child.

Verified on the shared devnet (5 validators, chain v1.20.2-rc1): after the
change, 210 uploads with 0 re-registrations sourced from the processed dir,
and processed_files advanced 1242 -> 1276.

Note for existing devnets: files already sitting in a nested <srcPath>/processed
must be moved out of the scan path before restarting, otherwise they are
re-registered once on the next pass.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant