Staging unav server [WIP] - #78
Open
surendhar-palanisamy wants to merge 34 commits into
Open
Conversation
- Switch unav-core to rizzojr01/unav-backend-core fork (exposes MASt3R matcher) - Dispatch to mast3r_matching_and_pnp when local_feature_model=mast3r - Save query image to temp path and stash on localizer - Log candidate count, matcher type, and resolved DB image paths - Add docs/FIX_LOCALIZATION_NO_MATCHING_STEP.md tracking the fix - Ignore planner_output.json
…ints drowned in otel noise
…ed, not just selective)
…er class is actually used
…e data_temp/final for MASt3R matcher
…keep main config on DATA_ROOT
- modal_config.py: pip_install_private_repos now points at github.com/ai4ce/UNav.git (the canonical source matching the local unav/ submodule HEAD aa60dc9, which ships mast3r_matching_and_pnp with the multi data_roots / pp kwarg fixes). Added force_build=True so Modal does not reuse a cached unav install layer that pre-dates the matching dispatch. - docs/DEPLOYMENT_CHANGES.md: appended a 2026-06-26 entry for integrate_backend_snap_to_route documenting the unav source swap and the rationale for not touching the MASt3R matching / data-root logic already present from add_temp_config.
The staging ufbuj account has metrics/logs/traces export disabled, which makes every OTLP export attempt log a full grpc traceback and drown out the actual application logs. Neutralize the middleware initialization: - run_init_middleware: no-op that just clears _middleware_init_pending and sets self.tracer = None. - _configure_middleware_tracing: no-op for the same reason; kept as a function so the deferred-init call site in run_init_gpu_components remains valid. Downstream code that checks 'tracer is not None' falls through to the non-traced localize_user / planner path.
The upstream UNavLocalizer.batch_local_matching_and_ransac (in unav/unav/localizer/localizer.py) now accepts a pp kwarg per the aa60dc9 submodule update. Our traced_match wrapper in localizer.py:137 had a fixed signature without pp, so calls like orig_match(self, ..., pp=pp) raised: TypeError: UNavLocalizer.batch_local_matching_and_ransac() got an unexpected keyword argument 'pp' Adding pp=None to the wrapper signature and forwarding it.
This reverts commit 312eee7.
Records every commit on integrate_backend_snap_to_route today (2026-06-26), what each change did, what the deployment log showed afterwards, and what was concluded. Includes the outstanding items: stale Modal image (pp fix not live), OTLP noise, and the unmapped- location error that needs a full traceback.
The image was running: git clone https://github.com/ai4ce/UNav-Server.git unav_server_v2 git checkout endeleze (plus debug pwd/ls/branch prints) This is redundant: the unav Python package is installed via pip_install_private_repos(ai4ce/UNav.git), and Modal's auto-include mechanism (via @app.cls in unav_modal.py) ships src/modal_functions/ unav_v2/localizer.py from the local working copy at deploy time. The clone of the whole UNav-Server into /root/unav_server_v2/ is never referenced by the running app — it's dead weight in the image. More importantly, the 'git checkout endeleze' was pulling a stale endeleze branch into the image while the real app code came from Modal's auto-include, causing the pp=None fix to be live in the auto-included wrapper but not in the cloned /root/unav_server_v2/. Removing the redundant clone also eliminates that dual-source confusion.
The same TypeError surfaced in the deployed container because there are TWO wrappers of UNavLocalizer.batch_local_matching_and_ransac: src/modal_functions/unav_v2/localizer.py:137 (already had pp=None) src/modal_functions/unav_v2/logic/maps.py:146 (this one — was missing pp) The one in logic/maps.py runs at GPU init time and overwrites the one in localizer.py, so it's the active wrapper in the container. Add pp=None to its signature and forward it on both the MASt3R and the SuperPoint paths.
The installed unav package in the container has the signature conflict: the upstream UNavLocalizer.batch_local_matching_and_ransac in unav/localizer/localizer.py accepts pp, but the underlying mast3r_matching_and_pnp the wrapper calls directly rejects it. Drop pp=pp from the direct mast3r_matching_and_pnp call site in logic/maps.py:166 so the function receives only the kwargs it accepts. The wrapper still receives pp (from the dispatcher) but does not forward it to the matcher.
…error - middleware-io's distro.py imports pkg_resources, which was removed in recent setuptools releases (80+). Pin setuptools<70 so pkg_resources remains available at container startup. - Also update private unav repo URL to github.com/rizzojr01/unav.git.
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.
No description provided.