Skip to content

fix(plugins): treat kuaidi100's no-result row as a missing trace - #1091

Open
lihongyuan99 wants to merge 1 commit into
TencentCloud:developfrom
lihongyuan99:fix/parcel-tracker-no-result-placeholder
Open

lihongyuan99 wants to merge 1 commit into
TencentCloud:developfrom
lihongyuan99:fix/parcel-tracker-no-result-placeholder

Conversation

@lihongyuan99

@lihongyuan99 lihongyuan99 commented Sep 23, 2026 •

Copy link
Copy Markdown
Contributor

Summary

track_parcel promises a fallback link when a number cannot be found ("查不到时返回快递100 网页链接", src/octop/infra/agents/plugins/bundled/parcel-tracker/main.py:102-103), but for most unresolvable numbers that branch never runs.

For a number the carrier has nothing for, the free endpoint does not answer with an empty data array — it answers HTTP 200 with status: "200" and a single placeholder row:

{"message":"ok","nu":"78123456789012","ischeck":"1","com":"zhongtong","status":"200",
 "condition":"F00","state":"3",
 "data":[{"time":"2026-09-18 07:12:03","context":"查无结果","ftime":"2026-09-18 07:12:03"}]}

(verbatim reply captured on 2026-09-24; the same shape came back for yuantong/88888888888888, zhongtong/12345678901234, and for a zhongtong number queried under the wrong comCode.)

_query() collects that row as a normal trace, so track_parcel skips the if not traces fallback (main.py:90-92) and reports the placeholder as the newest status (main.py:93-94). Running the real code path end to end:

company auto-detected -> zhongtong
traces -> [{"time": "...", "context": "查无结果", "status": "200"}]
error key present -> False
text -> 78123456789012(zhongtong)最新:查无结果

So the model reads "最新:查无结果" as the parcel's latest status and the user never sees the query link. This is easy to hit because company is normally guessed by autoComNum, and a wrong guess produces exactly this reply rather than an error.

Fix: recognise the placeholder inside _query, so the existing "暂无轨迹 + 链接" branch handles it. Only the single-row placeholder is dropped, so a real history that happens to end on that text is untouched.

Target branch

  • Base is develop (feature / fix — default)
  • Base is main (release/* or hotfix/* only)

Type of change

  • Bug fix
  • New feature
  • Breaking change
  • Documentation
  • Refactor / chore
  • Release / hotfix

Test plan

Ran the equivalent backend commands by hand rather than make all, because this clone has no dashboard node_modules and make all shells out to npm run build.

  • Red first, tests only: uv run pytest tests/unit/test_parcel_tracker_plugin.py -q → 1 failed, 2 passed (_query returned the placeholder row); re-measured after rebasing onto develop@4667bd7b → 1 failed, 2 passed in 1.67s, and green with the fix → 3 passed in 1.37s.
  • After the fix: uv run pytest tests/unit/test_parcel_tracker_plugin.py -q → 3 passed.
  • uv run ruff check src tests → All checks passed!; uv run ruff format --check src tests → 1081 files already formatted.
  • uv run mypy src/octop → Success: no issues found in 530 source files.
  • Full suite: uv run pytest -q -m "not live" -n auto → 3850 passed, 17 skipped, 0 failed, against 3847 passed / 17 skipped / 0 failed measured on the base commit this branch was just rebased onto (develop@4667bd7b); the +3 are exactly the new cases.

The new tests are offline: the mock payloads are the captured kuaidi100 replies above, and httpx.Client is monkeypatched, so no network, key or carrier account is needed. They pin three behaviours — carrier auto-detection still reads auto[0].comCode, a real multi-row history is returned unchanged, and the placeholder collapses to "no traces" with the link and error: "no traces".

Checklist

  • Updated CHANGELOG.md (if user-facing)
  • README / docs updated (if needed) — not needed
  • No breaking change

Rebased onto develop@ded7addd on 2026-09-30. 1.0.2b4 and 1.0.2b5 both shipped since the previous base, and each release commit folded the whole ## [Unreleased] list into a version block, which emptied that section on develop — it is this branch's only conflict. The resolution keeps develop's CHANGELOG.md verbatim and re-inserts this PR's single bullet under a fresh ### 修复; nothing else changed.

Everything below was re-measured on develop@ded7addd. Backend gates were run by hand, as the equivalents of the CI steps (make lint / make typecheck / make test); make all was not used because this clone has no dashboard/node_modules.

  • Red, with this PR's fix reverted and only its tests: uv run pytest -q tests/unit/test_parcel_tracker_plugin.py -> 1 failed, 2 passed in 4.20s
  • Green as committed: the same command -> 3 passed in 1.51s
  • uv run ruff check src tests -> All checks passed!; uv run ruff format --check src tests -> 1112 files already formatted
  • uv run mypy src/octop -> Success: no issues found in 543 source files
  • Full suite uv run pytest -q -m "not live" -n 6 -> 3956 passed, 17 skipped, 1 failed in 216.99s, against 3953 passed, 17 skipped, 1 failed in 225.23s measured on the unmodified base commit in the same virtualenv. The single failure in both runs is tests/unit/test_plugin_manager.py::test_install_plugin_importing_legacy_harness_agent: legacy_imports.ensure_legacy_harness_agent_alias() deliberately leaves a real harness_agent distribution alone, and this local venv has an out-of-lock orcakit-harness-agent installed, so the alias assertion cannot hold here. It is pre-existing on the base, not a case this PR adds, and it is green in CI, which installs strictly from uv.lock (the Python 3.12 quality job is success on both this branch's pre- and post-rebase heads).
  • tests/live was not run; no model API key, PostgreSQL or Docker was needed.

Rebased onto develop@83b2ae2e7 (2026-10-03).

Four commits landed on develop since this branch's previous base (a02e3e18e): LDAP directory login (#1123), propagating exhausted model retries as failures (#1012), and two dashboard fixes (#1429, #1241) — each appended a bullet to ## [Unreleased], so CHANGELOG.md is this PR's only conflict. The resolution keeps develop's CHANGELOG.md verbatim and re-inserts this PR's single line into the existing ### 修复 list: git diff origin/develop 405ae708d -- CHANGELOG.md is +1/-0, and git diff 19fdaccd01 405ae708d1 over every non-CHANGELOG file of the PR is empty, i.e. the code you already reviewed is byte-identical.

Re-measured on the new base with the same commands and the same virtualenv as the Test plan above:

  • ruff check src tests → All checks passed!
  • ruff format --check src tests → 1134 files already formatted
  • mypy src/octop → Success: no issues found in 551 source files
  • this PR's own tests: pytest -q tests/unit/test_parcel_tracker_plugin.py → 3 passed in 1.78s
  • full suite pytest -q -m "not live" -n 3 → 1 failed, 4135 passed, 17 skipped, 13 warnings in 429.12s (0:07:09) (three branches measured concurrently, so the wall time is inflated), against 4132 passed, 17 skipped, 1 failed in 218.55s measured on the unmodified base 83b2ae2e7 in this same virtualenv: +3 cases against the base, which are exactly this PR's. The single failure in both runs is the pre-existing local artifact tests/unit/test_plugin_manager.py::test_install_plugin_importing_legacy_harness_agent — this venv has an out-of-lock orcakit-harness-agent distribution installed, and that test deliberately leaves a real harness_agent package alone, so its alias assertion cannot hold here. It is red on the untouched base too and green in CI, which installs strictly from uv.lock.

2026-10-06 — CHANGELOG.md re-aligned with develop. A rebase of this branch had re-introduced other PRs' release-note bullets into the released ## [1.0.2b6] block, so this PR's diff carried those foreign lines instead of only its own. CHANGELOG.md is now develop's file verbatim plus this PR's single bullet under ## [Unreleased] → ### 修复:

  • git diff --numstat 75c274aef ecc17a400 -- CHANGELOG.md → 1\t0\tCHANGELOG.md
  • git diff --name-only aff9a4c27 ecc17a400 → CHANGELOG.md only, so every code and test file is byte-identical to the head that Python 3.12 and Windows / Python 3.12 both reported success on;
    the commands and counts under Test plan therefore still describe this diff.
  • CHANGELOG.md at 75c274aef is identical to today's develop tip, so this does not need a fresh rebase.

Rebased onto develop@97d6e7ff4 (2026-10-12); head ecc17a400 -> 57271868a.

CHANGELOG.md is again this branch's only conflict, and the resolution keeps develop's file
verbatim and re-inserts only this PR's own bullet under its matching ### subsection — checked
mechanically: the diff against the new base is 1 added / 0 deleted in CHANGELOG.md
and byte-identical (hunk headers aside) for 2 code/test file(s) before and after the
rebase. Gates re-run by hand on the new head (make all still does not apply — no
dashboard/node_modules in this clone; the venv is created per worktree so
/Users/macos/Documents/Qoder/octop-pr-mining/repos/wt-r-1091/src/octop/__init__.py is this branch's own code):

  • targeted tests for this branch: 3 passed in 22.46s
  • full suite: 4630 passed, 26 skipped, 19 warnings in 426.26s (0:07:06), against develop@97d6e7ff4 measured in the same venv: 4627 passed, 26 skipped, 0 failed
  • All checks passed!; 1180 files already formatted; Success: no issues found in 570 source files

Rebased onto develop@87a8d52c2 (2026-10-14); head 57271868a -> 8a587c688.

CHANGELOG.md is again the only conflict. develop's file is kept verbatim and this PR's own
bullet is re-inserted into the current ## [Unreleased] list, which is now flat (no ###
subsections), so the diff against the new base is 1 added / 0 deleted there and the
2 code/test file(s) are byte-identical before and after (hunk headers aside) — checked
mechanically, not by eye. Gates re-run by hand on the new head (make all still does not apply:
no dashboard/node_modules in this clone; the venv belongs to this worktree, so
/Users/macos/Documents/Qoder/octop-pr-mining/repos/wt-r-1091/src/octop/__init__.py is this branch's own code):

  • RC ruff=0 format=0 mypy=0 targeted=0 full=0
  • targeted tests for this branch: 3 passed in 6.76s
  • full suite: 4682 passed, 26 skipped, 41 warnings in 233.91s (0:03:53), against develop@87a8d52c2 measured in the same environment today: 4679 passed, 26 skipped, 0 failed
  • All checks passed!; 1186 files already formatted; Success: no issues found in 571 source files

Rebased onto develop@99e479a6b (2026-10-16); head 7aabba036 -> da379751d.

CHANGELOG.md was again the only conflict: develop's file is kept verbatim and this PR's own bullet is re-inserted under its matching ### subsection of the current ## [Unreleased] block, so the diff against the new base is 1 added / 0 deleted there and the 2 code/test file(s) are byte-identical before and after the rebase (checked mechanically on the patch hash, not by eye). Gates re-run by hand on the new head (make all still does not apply — no dashboard/node_modules in this clone; the venv belongs to this worktree, so the checkout under test is this branch's own code):

  • RC ruff=0 format=0 mypy=0 targeted=0 full=0
  • targeted tests for this branch: 3 passed in 3.97s
  • full suite: 4783 passed, 32 skipped, 41 warnings in 470.21s (0:07:50), against develop@99e479a6b measured today in its own per-worktree venv on the same machine: 4780 passed, 32 skipped, 0 failed in 495.68s
  • All checks passed!; 1204 files already formatted; Success: no issues found in 581 source files

@lihongyuan99
lihongyuan99 force-pushed the fix/parcel-tracker-no-result-placeholder branch 5 times, most recently from 3c51e2a to 19fdacc Compare September 30, 2026 15:56
@lihongyuan99
lihongyuan99 force-pushed the fix/parcel-tracker-no-result-placeholder branch 4 times, most recently from aff9a4c to ecc17a4 Compare October 5, 2026 23:14
@lihongyuan99
lihongyuan99 force-pushed the fix/parcel-tracker-no-result-placeholder branch 3 times, most recently from 8a587c6 to 7aabba0 Compare October 14, 2026 23:18
@lihongyuan99
lihongyuan99 force-pushed the fix/parcel-tracker-no-result-placeholder branch from 7aabba0 to da37975 Compare October 15, 2026 23:15

This branch has not been deployed

No deployments
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