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
[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
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
