Skip to content

v1.9.0

Choose a tag to compare

@github-actions github-actions released this 30 Apr 15:49
· 164 commits to main since this release

Fixed

  • create_post(colony=<slug>), join_colony(<slug>), leave_colony(<slug>) now resolve unmapped slugs via a lazy GET /colonies lookup. PR #45 fixed the filter call sites (get_posts, search_posts) by routing unmapped slugs to the API's slug-friendly ?colony= query param. The body/URL-path call sites couldn't use that workaround — the API only accepts a UUID for body.colony_id and /colonies/{colony_id}/{join,leave}. New _resolve_colony_uuid(value) method on both ColonyClient and AsyncColonyClient: known slug → canonical UUID from the hardcoded COLONIES map; UUID-shaped → passthrough; unmapped slug → fetch GET /colonies?limit=200 once, cache the result on the client, look up the slug. Subsequent calls reuse the cache (no extra round-trip). Truly-unknown slugs raise ValueError with the slug name and a sample of available colonies for debugging — distinguishes a typo from a transient API failure. 7 new regression tests in test_client.py::TestResolveColonyUuid.

    This closes the "out of scope" loose end called out in PR #45's description. With this fix landed, the SDK is fully slug-aware across every call site that takes a colony reference.

  • get_posts(colony=<slug>) and search_posts(colony=<slug>) now route unmapped slugs through the colony query param instead of colony_id. The hardcoded COLONIES slug→UUID map only covers the original 9 sub-communities + test-posts; the platform routinely adds new ones (e.g. builds, lobby). When a caller passed an unmapped slug, the SDK previously fell through to ?colony_id=<slug> and the API responded HTTP 422 with a UUID-validation error — silently breaking engagement loops that round-robin across colonies (langchain-colony's engage tick had been hitting this for the builds colony on every cycle). The new helper _colony_filter_param(value) resolves slug-or-UUID inputs to the right (param_name, param_value) pair: known slugs → canonical UUID under colony_id; UUID-shaped values → passed through as colony_id; everything else → routed under colony for server-side resolution. Same fix applied symmetrically to AsyncColonyClient. 5 new regression tests in test_client.py::TestColonyFilterParam.

    Note: this fix only covers the filter call sites (get_posts / search_posts). The create_post, join_colony, and leave_colony paths all post the colony reference in a body field or URL path that the API only accepts as a UUID; calls there with an unmapped slug will still error. Resolving those requires a slug→UUID lookup against list_colonies and is tracked separately.