Skip to content

[DOM-75516] feat: leaderboard normalization utils + request project ID resolver#13

Merged
ddl-subir-m merged 5 commits intomainfrom
subir/pr3-leaderboard-api-utils
Mar 24, 2026
Merged

[DOM-75516] feat: leaderboard normalization utils + request project ID resolver#13
ddl-subir-m merged 5 commits intomainfrom
subir/pr3-leaderboard-api-utils

Conversation

@ddl-subir-m
Copy link
Copy Markdown
Collaborator

@ddl-subir-m ddl-subir-m commented Mar 20, 2026

Why

Leaderboard normalization: AutoGluon's TimeSeries models report training time as fit_time_marginal but omit the fit_time field that tabular models produce. The frontend leaderboard table, diagnostics panels, and model export all expect fit_time. Rather than adding fallback logic in every consumer, this PR adds a normalization layer that copies fit_time_marginalfit_time when absent.

Project ID resolution: Multiple endpoints need to know which Domino project the request is for (dataset listing, upload, job launch). The project ID can arrive via X-Project-Id header, projectId/project_id query param, or the DOMINO_PROJECT_ID env var. Rather than duplicating this resolution logic across routes, resolve_request_project_id() centralizes it.

Summary

  • Adds normalize_leaderboard_rows() and normalize_leaderboard_payload() — copies fit_time_marginalfit_time only when fit_time is missing
  • Adds resolve_request_project_id() — checks X-Project-Id header → query params → env var

File → consumer mapping

File First consumed by
leaderboard_utils.py PR #22 (leaderboard routes call normalize_leaderboard_payload)
utils.py (resolve_request_project_id) PR #25 (routes/datasets.py calls it for project-scoped dataset listing)

These are small shared utilities (~45 lines each) grouped here because they're both "request context extraction" helpers. Each is fully tested in this PR.

Test plan

  • test_leaderboard_utils.py passes
  • test_api_utils.py passes
  • normalize_leaderboard_rows copies fit_time_marginalfit_time only when fit_time is missing
  • resolve_request_project_id returns correct value for header, query param, and env var inputs

…lver

- Add normalize_leaderboard_rows/payload to fix TimeSeries fit_time display
- Add resolve_request_project_id() to centralize project context extraction
  from X-Project-Id header, query params, and DOMINO_PROJECT_ID env var

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@ddl-subir-m ddl-subir-m requested review from a team and niole March 20, 2026 14:45
@ddl-subir-m ddl-subir-m changed the title feat: leaderboard normalization utils + request project ID resolver [DOM-75516] feat: leaderboard normalization utils + request project ID resolver Mar 23, 2026
ddl-subir-m and others added 3 commits March 23, 2026 22:08
…roject_id

The env var is the App's own project, not the target project the user
is working in. Falling back to it silently operates on the wrong project
(root cause of datasets showing empty in cross-project scenarios).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Query params are the canonical approach going forward. The X-Project-Id
header is kept as a fallback for legacy clients only.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The frontend sends both header and query param from the same source.
No scenario where header is present but query param isn't. Query param
only — simpler.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@ddl-subir-m ddl-subir-m merged commit b8cee49 into main Mar 24, 2026
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.

2 participants