somehow DbContext.threadLocal stuck on UI thread after some previous tests, resulting in poisoned DbContext on the thread of db-free tests. DbContext.isBound returns true, and consequent db reads fail with poison-exception, resulting in massive test failures.
GitOrigin-RevId: 2dc6b487761ab408bc1b78e49558424c89e8abd5
- it was considered a safe default, but people are surprised by unexpected retries
- it is inconsistent with Query.launchOnEach and other query terminators e.g. collect
GitOrigin-RevId: 109c5a8e961bd00b50155767f78abe08e5531c77
intellij cancels the rpc coroutine tree while clients are connected to it and they need a way to expect the resulting exceptions
GitOrigin-RevId: 27816c012a489e55132f806d4622d7c9ec200cf9
[fleet] throw new exception on attempt to access poisoned DbContext to see the access stacktrace
[fleet] FL-29872 Failed to navigate to NavigationParameters: 'Resource didn't emit'
safer version of resource constructor
[fleet] preserve exception kind
[fleet] rebase
[fleet] FL-29573 Argument covariance in EntityAttribute allows to write incorrect code
GitOrigin-RevId: 2f1937bc18efb4031f8420d7290550291a3db30c
If the frontend receives an event, "stream_closed" with an exception (except for `CancellationException`), it shuts down kernel.
This leads to inability to recover after such disconnect.
In Fleet thrown `RuntimeException` indicates that something is wrong with a setup because the cancellation order is determined.
In the case of Intellij, this exception happens because we cancel only top-level coroutine scope and order of children cancellation is unknown.
Instead of closing the channel in `invokeOnCompletion`, it can be closed in finally after subscribed has been canceled.
This way we do both: support cancellation from above (intellij case) and ensure there is no out-of-scope subscription (fleet case)
GitOrigin-RevId: 3fa7c670bad7a81e404997a1a2d9fb3572c94125
Before, a contribution scope was a scope of opening. Any launch inside `Open` freezes the opening process. Now, the contribution scope lives while View is alive.
GitOrigin-RevId: c96bc10804d15b3996057f265b89a9c988aa1eb4
This was raising `attempted to query hidden partition: 4, allowed parts: [0, 2, 1]` issues depending on implementation
Also update the inspection to avoid further erroneous migration
GitOrigin-RevId: 89aa306fddd8f7207766da426bce4515395a83aa
As documented in the code, lookup() was able to work with `subclass::baseAttribute` and return all instances of the subclass that has the base attribute value. With the new API, more boilerplate is necessary at the moment.
For lookupOne, while the replacement would work in all cases, some may benefit from a simple `entity() as? Subclass`, but it has to be decided on a case-by-case basis.
This API would keep track of such cases.
GitOrigin-RevId: be9a435388959a1371e2dd90675f3bb3a6143bec
