Repository navigation
fix: regenerate from nebula@67d2b6e - #593
nebula-sdk-bot[bot] wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
Zero Review - 2 findings shown inline.
4,319,643 tokens used (4,291,652 prompt / 27,991 completion; 3,868,672 served from cache, billed ~10%).
Models - prime-root: zero/swe-root (1 agent, 1 task, 48 calls, 2,516,295 tokens), prime-child: zero/balanced (4 agents, 4 tasks, 50 calls, 1,803,348 tokens)
| self.memories: MemoriesResource = MemoriesResource(self._core) | ||
| self.enterprise: EnterpriseResource = EnterpriseResource(self._core) | ||
| self.marketplace: MarketplaceResource = MarketplaceResource(self._core) | ||
| self.memory: MemoryResource = MemoryResource(self._core) |
There was a problem hiding this comment.
🟡 Preserve or document the removed memory APIs
This replaces the existing client.memories resource with client.memory, while the same regeneration also deletes the handwritten store_memory and store_memories methods. There are no forwarding aliases and the migration guide does not mention this break. Existing code such as the previously documented client.store_memory(...) or client.memories.search(...) now raises AttributeError immediately after upgrading. A focused runtime probe at this head confirmed that all three attributes are absent. Please retain deprecated compatibility aliases/wrappers for the patch release, or explicitly treat and document this as a breaking release with a migration path.
Evidence
- At the merge base,
_client.pyconstructsself.memoriesand_dx.pyimplementsstore_memory/store_memories; the PR removes them. - Focused probe output:
has memories: False,has store_memory: False,has store_memories: False, followed byAttributeError 'Nebula' object has no attribute 'store_memory'.
| # the misroute is transient; the edge replays what it can, and retrying | ||
| # covers the requests it cannot (uncloneable bodies, unannotated routes). | ||
| _RETRYABLE_STATUSES: frozenset[int] = frozenset({421, 429, 503}) | ||
|
|
There was a problem hiding this comment.
🟡 Continue retrying transient 408/502/504 responses
The retryable status set is narrowed from {408, 429, 502, 503, 504} to {421, 429, 503}. Consequently, even generated read operations marked retryable=True now fail on the first 502/504 gateway error or 408 request timeout instead of using the configured retry budget. These are standard transient statuses, and removing them makes the SDK less resilient during proxy/load-balancer failures. A MockTransport probe returning 502 once and success next for client.health() made only one request and raised NebulaServerError. Please add 408, 502, and 504 back while retaining the new 421 handling.
Evidence
- The pinned diff directly removes 408, 502, and 504 from
_RETRYABLE_STATUSES. - Focused probe output:
NebulaServerError 1, confirming a retryable GET made only one attempt after a transient 502.
Zero ReviewSummary
2 per-line findings posted in the inline review. |
Automated SDK regeneration.
Source: zeroset-inc/nebula@67d2b6e
Generator: nebula-sdks/generator (@workos/oagen-backed)
Bump type:
fix(drives release-please's next version)Review the diff carefully — this is a release artifact. The in-tree
pyproject.tomlversion is0.0.0+from-source; release-pleaseowns the published version.