Conversation
Merged into jem-dev for branch-only release train.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c74e06fc3b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| self._generic_instance.category == category, | ||
| self._generic_instance.type == type_name, | ||
| self._generic_instance.subtype == "generic", |
There was a problem hiding this comment.
When this release is pointed at an existing Zebra Day TapDB namespace, rows created before this commit still use the old shape (category="ZGX" with subtypes like printer/template). Filtering only for the new category/type plus subtype == "generic" makes existing labs, printers, templates, profiles, and jobs disappear from list/get paths, and later upserts create duplicate records instead of updating the deployed fleet. Add an explicit migration/backfill for existing generic instances before switching these filters.
Useful? React with 👍 / 👎.
| conda_env = os.environ.get("CONDA_DEFAULT_ENV", "").strip() | ||
| if conda_env.startswith("ZEBRA_DAY-"): | ||
| return sanitize_deployment_code(conda_env.removeprefix("ZEBRA_DAY-")) |
There was a problem hiding this comment.
When a deployed process has DEPLOYMENT_CODE or LSMC_DEPLOYMENT_CODE set but is launched from a stale ZEBRA_DAY-* conda environment, this new branch returns the conda suffix before checking those explicit service deployment env vars. That makes ZebraDaySettings load the wrong deployment-scoped config and TapDB namespace, risking reads/writes against local or another environment. Either remove this inference or make it a last-resort after explicit deployment envs.
Useful? React with 👍 / 👎.
| if status >= 500: | ||
| return None | ||
| verified = "zebra" in haystack or "zpl" in haystack | ||
| return { |
There was a problem hiding this comment.
When scan_http_port is supplied on a mixed subnet, any HTTP service returning a status below 500 now produces a discovery payload because the Zebra/ZPL body check only sets http_verified. The caller writes every returned payload into TapDB as a draft Zebra printer, so ordinary routers, apps, or auth pages can pollute fleet state during a scan. Keep unverified probes out of discovery results or require explicit operator confirmation before saving them.
Useful? React with 👍 / 👎.
iamh2o
changed the title
1 participant
Summary
Validation
Release