Skip to content

chat using instance instead of class for downstream connectivity query #66

Closed

Description

@Clare72
Image

Activity

  1. Robbie1977 commented on Sep 11, 2026

    @Robbie1977
    Contributor

    Two separate faults here, both fixed in #69.

    1. Why it picked an instance. VFB's search ranks the ~500 KCg-* hemibrain individuals above the class whose symbol is KCg, so with 30 rows the resolver never saw gamma Kenyon cell at all and its token-superset fallback took the first individual carrying the token. The class lift added for #59 only applied to names like "EPG neurons"; it now also applies to a bare symbol that matched no document exactly when an exact match exists among classes. KCg is the symbol of two classes — adult gamma Kenyon cell (FBbt_00049828) and gamma Kenyon cell (FBbt_00100247) — and nothing in the question picks one, so the chat now asks: "KCg" matches more than one VFB term: adult gamma Kenyon cell or gamma Kenyon cell. Which did you mean? with a chip for each. A stage word in the question ("adult KCg") settles it without asking, and so does the model when the question itself decides (a dataset, a qualifier).

    2. Why the class answer was still wrong. With the class resolved, run_query DownstreamClassConnectivity came back count: 0 and the chat said VFB holds no downstream connectivity for gamma Kenyon cells. That zero is a leftover of the pre-1.22.51 silent-zero bug, still cached at the v3-cached edge under the URL shapes the MCP uses:

    run_query?id=FBbt_00100247&query_type=DownstreamClassConnectivity&offset=0&limit=25     -> count 0 (HIT)
    run_query?id=FBbt_00100247&query_type=DownstreamClassConnectivity&offset=0&limit=2500   -> count 0 (HIT)
    run_query?id=FBbt_00100247&query_type=DownstreamClassConnectivity                        -> count 3886 (the slot refreshed on 4 Sep)
    

    The chat now treats a class-connectivity count: 0 like a -1: one forced recompute on the existing per-request budget, and a second zero is believed. That protects users, but the stale slots should still be purged — every (Downstream|Upstream)ClassConnectivity body with "count": 0 cached before 4 Sep is suspect, on every cache instance (a force-refresh through one instance does not update the others' disks, which is why the plain-URL refresh only half-worked).

    Verified live: the question in the screenshot now asks which gamma Kenyon cell class was meant; choosing adult gamma Kenyon cell answers with 3,370 downstream classes ranked by synapses per connected pair (APL, DPM, MBON05, MBON01 leading).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions