`SortedMap.range` throws `StateNotConstructed` if you try a range query first.

[katfang]

To Reproduce
Try

await SortedMap.ref("sorted-map").range(context, limit=1)

Get StateNotConstructed error.

Expected behavior
Expect ... maybe an error saying that there's no items, or an empty list of items, but definitely not a StateNotConstructed error for a state that doesn't have a constructor.

Impact
How severely does this bug impact your use of Reboot?

• It's not having any negative impact
• It's annoying
• It's a serious problem
• It makes it impossible for me to use Reboot

Please explain why?

Alright for me because I happen to be accessing from a place where I can delay trying to read until after I've actually written.

Screenshots
If applicable, add screenshots to help explain your problem.

Client
Please complete the following information:

• OS: [e.g. macOS 14.6.1]
• Client [e.g. curl, grpcurl, Chrome, Safari, ...]
• Client version [e.g. 22.0.1]

Additional context
Add any other context about the problem here.

[rjhuijsman]

This comes down to a very old and still not quite concluded discussion about what the behavior of a reader on an unconstructed, implicitly constructable state should be.

Option 0: return StateNotConstructed, as current

This is the most "consistent", perhaps (see alternatives below). But as this issue points out, it's often surprising - and we do have have quite a few try: except blocks handling StateNotConstructeds now.

Option 1: The reader should run as if the state exists, but is empty.

Tricky semantics about this include:

• How do we lock nonexistent states when these reads occur in a transaction? Where do we persist those locks?
• What if the only available (implicit) writer does set up some prerequisites that the reader expects?
  • What if an empty state is illegal according to the Pydantic or Zod schemas, both of which support required fields?
• Does it make sense that you can call methods on something that doesn't exist?
• Would it be confusing that you can't see the thing you're calling a method on on your __/inspect page?
• ...

Option 2: The reader should construct an empty state

This would make readers sometimes have a writer's effect... 😬

Other ideas?

Let us know!

[rjhuijsman]

CC @benh for user feedback relevant to our previous discussions.

[benh]

The variant of option 2 I was previously convinced about I would describe as the following: support implicit construction for states that don't have an explicit constructor on calls to readers whenever atomicity is not a concern, including from React, from a WebContext, from an ExternalContext, from a WorkflowContext, and from a TransactionContext such that if the transaction aborts we "rollback" the construction.

That left two possible places you'd still get StateNotConstructed, readers and writers, versus the Option 2 presented here which implies that calling a reader from a reader or writer will construct an empty state.

We've complicated this a little bit, however, because even when you don't have an explicit constructor, you can still set values of your state to specific defaults in your writers or transactions by looking at context.constructor. So if we do allow readers to construct states, how do they set those defaults?

It makes me wonder if we want a world where you can annotate that your state is not only implicitly constructible but it is reader constructible.

But that is from the perspective of the author of the state, what about the consumer/user of the state? What if they are trying to capture an invariant about what the construction of a state means? If we allow a state to be constructed from all the places list above, i.e., React, ..., then presumably they will not be able to have any such invariants. So maybe there aren't really useful invariants?

So maybe we add an annotation which allows an author of state to specify that the state can be "reader constructed" and as Option 2 proposes it makes readers have effects? I can see setting that for a bunch of the collections, e.g., SortedMap, OrderedMap, maybe Queue, although I think that sets some defaults in its writers which perhaps could be changed to defaults in the definition (which works for Pydantic but not protobuf ...)

[rjhuijsman]

A variant of that idea: perhaps you could specify a "default" constructor - a method that's called when the state is implicitly constructed by a call to a non-constructor method. Such a default constructor would...

• not take any arguments (but would know its own state ID, so can e.g. update a primary index).
• get a TransactionContext for maximum flexibility on use-case (including e.g. updating primary indexes) - and anticipating that we'll eventually optimize transactions that don't leave their state.
• run after auth (which sees a None state), but before the call that prompted the implicitly construction.
• if not defined by the developer: produce an empty state.

The penguin then becomes: anybody who interacts with any method on the state may be implicitly constructing it. If you'd like to avoid malicious actors from using your disk space, you must carefully design your auth so you reject None states.

[rjhuijsman]

A completely different approach would be to remove implicit construction, in favor of the proven semantics of Object Oriented Programming:

1. Make it really easy to pass refs to objects/states around.
2. Require explicit construction by the caller; objects/states don't exist until they're constructed.
   • Objects/states have a default "empty" constructor, but developers can specify their own constructor(s) instead.
3. Objects/states can't be reffed if they don't exist (compare: memory address). You get a ref by getting it (transitively) passed to you by whoever constructed the object.
4. (perhaps do ref counting, so that automatic deletion of unused states is a thing)

These are just the semantics of OOP. Our additional problem is "bootstrapping": how does an external client get its first ref? Once it has one ref it can discover other refs, but how does it get the first?

I see two options:

Blocking lookups of explicit IDs:

ref = await MyStateType.lookup("my-explicit-id")  # This makes an RPC.

We've talked about this option before, but rejected it on the basis of how many roundtrips it then takes to interact with a state. I think it's a lot more interesting though if you assume that the vast majority of refs are passed to you in response to other calls, removing the need to do explicit lookups.

Note that this is already our reality, it's just that our "refs" are just string IDs. E.g. in the Cloud dashboard you load your "organizations" page by looking up the list of Organizations by caling User.Organizations() (which returns a repeated string organization_ids), then you ask for each Organization.Name(). This could instead return:

repeated Ref organizations [reboot.state_type = 'Organization']

... and no lookups would be needed.

Queries

# Find a state based on some property.
ref = await MyStateType.first().where().MyUserId().equals("my-own-id")

Note that in this variant the actual state ID is completely transparent to the user (just like memory addresses in OOP). They've defined their own MyUserId() method, and we've returned the first (only?) state that matches it.

If all state IDs are always system-assigned and never seen we also remove the confusion around "do I pass my state ID as a request field?" - customers simply won't think about their state IDs.

There are plenty of open questions here though, like: how do we construct indexes to make this remotely efficient?