Skip to content

fix(plugins): ask Bangumi for the response group that carries ratings - #949

Open
lihongyuan99 wants to merge 1 commit into
TencentCloud:developfrom
lihongyuan99:fix/movie-search-rating-response-group
Open

lihongyuan99 wants to merge 1 commit into
TencentCloud:developfrom
lihongyuan99:fix/movie-search-rating-response-group

Conversation

@lihongyuan99

@lihongyuan99 lihongyuan99 commented Sep 21, 2026 •

Copy link
Copy Markdown
Contributor

Summary

search_movie asked Bangumi for responseGroup=small, and that payload does not contain a rating field at all — so the score was always None, the card's rating line rendered empty, and the text summary printed — for every hit.

  • Request: src/octop/infra/agents/plugins/bundled/movie-search/main.py:28 ("responseGroup": "small").
  • The parser already expects the larger group: main.py:45-48 reads row["score"] and otherwise rating["score"] when rating is a dict. With small neither key is present, so that branch is dead code.
  • Both renderings of the score are therefore permanently blank: the card (bundled/movie-search/ui/index.js:40 → row.score != null ? \评分 ${row.score}` : "") and the text summary (main.py:77→({r['score'] or '—'})`).

Verified against the live API (same endpoint, same UA, keyword=葬花, type=2):

responseGroup keys returned per row rating
small (current) air_date, air_weekday, id, images, name, name_cn, summary, type, url absent
common same as small absent
large …, collection, eps, eps_count, rank, rating, … {"total": 12391, "count": {…}, "score": 7.5}

The fix is the one token that makes the existing parser and the existing card work: request large. End-to-end after the change, the real tool call now returns 葬送のフリーレン ~トークの魔法~ (8.3) instead of (—).

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

Added tests/unit/test_movie_search_plugin.py, following the offline pattern already used by
tests/unit/test_hot_topics_plugin.py (importlib load of bundled/movie-search/main.py + a
fake httpx.Client). The fake mirrors bgm.tv's contract — it only includes rating when the
request asks for the large group — so the test asserts the user-visible outcome (a score
reaches the payload and the text) rather than the literal parameter.

Re-measured after rebasing onto develop@4667bd7b by flipping the token back to small:

  • red: pytest -q tests/unit/test_movie_search_plugin.py -> 1 failed (AssertionError at the score == 7.5 check)
  • red, with its neighbours -> 1 failed, 6 passed
  • green: pytest -q tests/unit/test_movie_search_plugin.py -> 1 passed
  • green, with tests/unit/test_hot_topics_plugin.py tests/unit/test_bundled_plugins_layout.py -> 7 passed
  • ruff check src tests -> All checks passed!
  • ruff format --check src tests -> 1081 files already formatted
  • mypy src/octop -> Success: no issues found in 530 source files
  • full suite: pytest -q -m "not live" -n 6 -> 3848 passed, 17 skipped, 0 failed in 220s, against 3847 passed, 17 skipped, 0 failed measured on the base commit develop@4667bd7b (the +1 is this PR's new test)
  • tests/live was not run; no model API key or PostgreSQL was needed

Checklist

  • Updated CHANGELOG.md (if user-facing)
  • README / docs updated (if needed)

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 ### 修复; the rest of the patch is unchanged.

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_movie_search_plugin.py -> 1 failed in 5.05s
  • Green as committed: the same command -> 1 passed in 1.42s
  • 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 -> 3954 passed, 17 skipped, 1 failed in 216.68s, 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 46cf8c7d3 -- CHANGELOG.md is +1/-0, and git diff c2c9419bc7 46cf8c7d32 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_movie_search_plugin.py → 1 passed in 1.61s
  • full suite pytest -q -m "not live" -n 3 → 1 failed, 4133 passed, 17 skipped, 13 warnings in 423.92s (0:07:03) (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: +1 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 41a908f68 -- CHANGELOG.md → 1\t0\tCHANGELOG.md
  • git diff --name-only 5ec503e1d 41a908f68 → 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 41a908f68 -> f8d801ad5.

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-949/src/octop/__init__.py is this branch's own code):

  • targeted tests for this branch: 1 passed in 20.25s
  • full suite: 4628 passed, 26 skipped, 17 warnings in 421.90s (0:07:01), 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 f8d801ad5 -> 7e6ccfcaa.

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-949/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: 1 passed in 5.98s
  • full suite: 4680 passed, 26 skipped, 41 warnings in 235.53s (0:03:55), 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 f030aac99 -> b6763df09.

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: 1 passed in 3.97s
  • full suite: 4781 passed, 32 skipped, 41 warnings in 470.17s (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

@jubaoliang jubaoliang closed this Sep 22, 2026
@jubaoliang jubaoliang reopened this Sep 22, 2026
@lihongyuan99
lihongyuan99 force-pushed the fix/movie-search-rating-response-group branch 5 times, most recently from e957432 to fd0d4ba Compare September 29, 2026 23:20
@lihongyuan99
lihongyuan99 force-pushed the fix/movie-search-rating-response-group branch 5 times, most recently from 5ec503e to 41a908f Compare October 5, 2026 23:13
@lihongyuan99
lihongyuan99 force-pushed the fix/movie-search-rating-response-group branch 3 times, most recently from 7e6ccfc to f030aac Compare October 14, 2026 23:18
search_movie sent responseGroup=small, whose payload has no `rating` key at
all, so the `rating` -> `score` branch never ran and every card line rendered
an empty score while ui/index.js still renders `评分 ${row.score}`.
@lihongyuan99
lihongyuan99 force-pushed the fix/movie-search-rating-response-group branch from f030aac to b6763df 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.

2 participants