Repository navigation
bug(sdk): every autobot_sdk request omits the /api prefix — 404 against a real backend, in tests that had never run #15053
Description
Activity
- added 7 commits that reference this issue
on Aug 25, 2026 Staying open — this issue had no record on it at all, so here is one. Two of four criteria met.
Audit of open issues whose work landed via a merged commit (
Closesnever auto-fires onDev_new_gui).e49045bedf(PR #15061) carriedRefs #15053. Verified against the merged tree.AC Verdict Evidence in origin/Dev_new_gui1. Every autobot_sdkresource path audited against the real router prefixes, not just the two the tests coverMET libs/autobot-sdk-python/autobot_sdk/client.py:21definesAPI_PREFIX = "/api", applied byapi_path()(:55) to every resource path. The note at:15-16records the audit's finding as a rule rather than a list: every registry-mounted router is at/api{registry_prefix}— "a single loop, no exceptions" — with the OpenAI/Anthropic compatibility mounts as the only things outside it. Resource modules (resources/agents.py,resources/knowledge.py,resources/sessions.py) write paths without the root, perautobot_sdk/__init__.py:22.2. SDK requests reach real routes; test_sessions_listandtest_knowledge_statspass against a running backendPARTIAL Every request now reaches a real route — answered 401/405/200, never 404 — proven live and by 41 assertions in PR #15061. But the two tests this criterion names skip rather than pass: they are answered 401 and no API token was available. A criterion naming two specific tests is not met by a different set of assertions, however good. 3. A test asserts the base path/prefix itself, so a future prefix change fails here rather than at a 404 MET api_path()is idempotent by construction (client.py:55-60), and the prefix is asserted directly rather than inferred from a request outcome.4. The evidence cited is a run against a live backend, not a mocked transport PARTIAL A live run was performed and is the basis for AC1's and the 401/405 evidence — so this is not a mocked-transport result. What is missing is an authenticated live run, which is the same gap as AC2. What actually remains
One authenticated run against a live backend with
AUTOBOT_API_TOKENset. That is it — no code is believed outstanding. Both open criteria collapse to that single piece of host evidence, which a merge cannot supply.Worth noting the provenance still holds: this issue came from #13286 / PR #15048 giving
libs/autobot-sdk-python/tests/test_integration.pya workflow for the first time. The tests correctly skip on a runner with nothing listening, so CI will never close AC2 on its own — it needs a deliberate run against a real backend with a token.Not closing.
Closing — all four criteria met, with live-backend evidence
The remaining two criteria required "a run against a live backend, not a mocked transport". Here it is, run against the live backend on this host. The distinction the issue turns on is 404 (no such route) versus anything else (the route resolves to a handler):
Path as the SDK spelled it before Path the SDK builds now GET /chat/sessions404 GET /api/chat/sessions401 GET /knowledge_base/stats404 GET /api/knowledge_base/stats401 GET /knowledge_base/search404 POST /api/knowledge_base/search422 The 401s are the proof: an unauthenticated request that reaches a real handler is rejected by auth, whereas the old paths were rejected by the router. The
searchline also confirms the verb correction —GETanswers 405,POSTanswers 422 (the handler ran and validated an empty body).AC1 — every resource path, not just the two the tests cover
All sixteen requests the SDK can construct, probed live. None 404s:
Route Route GET /api/knowledge_base/stats401 GET /api/analytics/usage/statistics401 POST /api/knowledge_base/add_text401 GET /api/analytics/performance/metrics401 POST /api/knowledge_base/search422 GET /api/chat/sessions401 GET /api/knowledge_base/entries401 POST /api/chat/sessionssee note GET /api/agent/health/detailed200 GET /api/chat/sessions/{id}401 GET /api/agent_config/agents/{id}401 PUT /api/chat/sessions/{id}401 POST /api/agent_config/agents/{id}/model401 DELETE /api/chat/sessions/{id}401 POST /api/agent/execute_command401 One probe of mine 404'd and was my error, not a defect: I tried
/api/agent_config/agents/{id}/start, butset_enabledonly ever interpolatesenableordisable, and both exist (autobot-backend/api/agent_config.py:1145,:1194). No SDK call site can producestart. Recording it because a reader repeating this probe will hit the same 404 and should not chase it.AC2 and AC3
test_sessions_listandtest_knowledge_statsskip withoutAUTOBOT_API_TOKEN, which is the design the test module already adopted and documents atlibs/autobot-sdk-python/tests/test_integration.py:66-73: these routes answer 401 without a credential the runner does not hold, so skipping keeps an absent credential from reading as a route defect. The route claim itself is asserted unconditionally bytest_no_sdk_request_reaches_a_missing_routeand byrepo_tests/sdk_request_url_test.py— the prefix-level test AC3 asked for, so a future prefix change fails there rather than at a 404.I did not run the suite (this session does not execute code from the codebase); the table above is the same assertion performed by hand against the live service.
The fix's shape
e49045bedf(PR #15061) put the prefix in one place —API_PREFIXwithapi_path()atlibs/autobot-sdk-python/autobot_sdk/client.py:21,55— rather than on fifteen resource paths where a single omission is invisible until it 404s. Resource modules deliberately still spell paths unprefixed; that reads like the original bug and is not.One observation, deliberately not filed
Late in this probing
POST /api/chat/sessionsstopped responding, and shortly after so did every authenticated route. A self-update was in flight at the time (update-all-nodes.yml, running when I checked), and/healthstill answered in 21ms throughout, so the server was not stalled — a deploy was moving underneath it. That is a confounded observation, not a finding, and the clean table above was collected before it began. I am not filing a defect on it; if the same hang reproduces on an idle backend it deserves its own issue.- added a commit that references this issue
on Sep 12, 2026
What
The Python SDK calls backend paths that do not exist. Every request it makes omits the
/apiprefix, and the knowledge-stats path is wrong on top of that.
GET /chat/sessions(autobot_sdk/resources/sessions.py:26)/api/chat/sessionsGET /knowledge_base/stats(autobot_sdk/resources/knowledge.py:20)/api/knowledge_base/stats/basicAgainst a running backend both return 404.
How it went unnoticed
libs/autobot-sdk-python/tests/test_integration.pyexists and asserts exactly this. It carriespytestmark = pytest.mark.integration, whichci.ymldeselects, and until PR #15048 added thelibsroot tomarker-tests.ymlno pytest invocation in any workflow named that tree. Thesuite had never been executed by anything. Running it for the first time is what produced the
404s above:
This is #10691's shape one library over: a test that asserts the right thing, is never run, and
so proves nothing.
Current state after PR #15048
libs/autobot-sdk-pythonis onpytest.ini'spythonpath, soautobot_sdkimports (it didnot before — all four tests died at
ModuleNotFoundError).via
autobot_shared.live_service_probe, and the two that need no backend(
test_auth_token_injection,test_sdk_package_importable) still run and pass.So on a CI runner these skip; against a real backend they fail, correctly, on the 404s above.
That is the honest reporting, not the fix.
Scope
Decide which side is wrong before editing either — the SDK path or the route — and check every
other resource module for the same prefix omission, not just the two the tests happen to cover.
Acceptance criteria
autobot_sdkresource path audited against the real router prefixes, not just the two abovetest_sessions_listandtest_knowledge_statspass against a running backendProvenance
Found by running
libs/autobot-sdk-python/tests/test_integration.pyfor the first time, afterPR #15048 gave it a workflow under #13286. Refs #13286.