fix: missing @fallible decorator for public methods in ops mod

[quettabit]

closes #70

[greptile-apps]

Greptile Summary

This PR fixes four public synchronous methods that were missing the @fallible decorator, meaning validation errors (e.g. from validate_basin, validate_encryption_key, validate_max_unacked, validate_batching) would escape as raw exceptions instead of being wrapped in S2ClientError.

• S2.basin() and S2Basin.stream() — factory methods that call validators before constructing the child object; now consistently wrapped.
• S2Stream.append_session() and S2Stream.producer() — session/producer factory methods that validate backpressure and batching parameters; now consistently wrapped.

Confidence Score: 5/5

Safe to merge — the change is a targeted, additive fix with no logic changes.

Four sync factory methods that call validators were silently letting raw exceptions escape the public API. The fix is minimal and correct: each newly decorated method already had the right logic, just needed the wrapper. The only pre-existing gap left open is S2Stream.init, which is protected indirectly by the @Fallible on S2Basin.stream().

No files require special attention beyond the single changed file.

Important Files Changed

Filename	Overview
src/s2_sdk/_ops.py	Adds missing @Fallible decorator to four public factory/session methods — S2.basin, S2Basin.stream, S2Stream.append_session, and S2Stream.producer — so that validation errors in those sync methods are consistently wrapped in S2ClientError.

Sequence Diagram

sequenceDiagram
    participant Caller
    participant basin as S2.basin() @fallible
    participant stream as S2Basin.stream() @fallible
    participant append_session as S2Stream.append_session() @fallible
    participant producer as S2Stream.producer() @fallible
    participant fallible as fallible wrapper
    participant validator as validators

    Caller->>basin: basin("invalid-name")
    basin->>validator: validate_basin(name)
    validator-->>basin: raises ValueError
    basin->>fallible: catches Exception
    fallible-->>Caller: raises S2ClientError

    Caller->>stream: "stream(name, encryption_key=...)"
    stream->>validator: validate_encryption_key(key)
    validator-->>stream: raises ValueError
    stream->>fallible: catches Exception
    fallible-->>Caller: raises S2ClientError

    Caller->>append_session: "append_session(max_unacked_bytes=...)"
    append_session->>validator: validate_max_unacked(...)
    validator-->>append_session: raises ValueError
    append_session->>fallible: catches Exception
    fallible-->>Caller: raises S2ClientError

    Caller->>producer: "producer(batching=...)"
    producer->>validator: validate_batching(...)
    validator-->>producer: raises ValueError
    producer->>fallible: catches Exception
    fallible-->>Caller: raises S2ClientError

Loading

Comments Outside Diff (1)

1. src/s2_sdk/_ops.py, line 935-962 (link)

   S2Stream.__init__ is missing @fallible while both S2.__init__ (line 97) and S2Basin.__init__ (line 661) have it. Because S2Stream is documented as "Do not instantiate directly" and is only created from S2Basin.stream() (which now has @fallible), any exception raised during __init__ will still be wrapped via the outer call. However, if a caller ever constructs S2Stream directly (e.g. in tests or subclassing), exceptions from its constructor — such as a Retrier initialisation failure — would escape unwrapped. Adding @fallible to __init__ would bring it in line with the other two classes in this module.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: src/s2_sdk/_ops.py
   Line: 935-962
   
   Comment:
   `S2Stream.__init__` is missing `@fallible` while both `S2.__init__` (line 97) and `S2Basin.__init__` (line 661) have it. Because `S2Stream` is documented as "Do not instantiate directly" and is only created from `S2Basin.stream()` (which now has `@fallible`), any exception raised during `__init__` will still be wrapped via the outer call. However, if a caller ever constructs `S2Stream` directly (e.g. in tests or subclassing), exceptions from its constructor — such as a `Retrier` initialisation failure — would escape unwrapped. Adding `@fallible` to `__init__` would bring it in line with the other two classes in this module.
   
   How can I resolve this? If you propose a fix, please make it concise.

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
src/s2_sdk/_ops.py:935-962
`S2Stream.__init__` is missing `@fallible` while both `S2.__init__` (line 97) and `S2Basin.__init__` (line 661) have it. Because `S2Stream` is documented as "Do not instantiate directly" and is only created from `S2Basin.stream()` (which now has `@fallible`), any exception raised during `__init__` will still be wrapped via the outer call. However, if a caller ever constructs `S2Stream` directly (e.g. in tests or subclassing), exceptions from its constructor — such as a `Retrier` initialisation failure — would escape unwrapped. Adding `@fallible` to `__init__` would bring it in line with the other two classes in this module.

_{Reviews (1): Last reviewed commit: "initial commit" | Re-trigger Greptile}