If RPC is not followed, backend throws an error `No remote API found for InstanceId` in `RemoteApiRegistry.resolve`.
`RpcExecutor`, however, expects this method to return `null` if service was not found, not an exception.
Therefore, the exception is propagated upward which breaks the kernel and prevents further RPC calls from executing.
We should adhere to the API requirements and return `null` if service was not found instead of throwing an error.
GitOrigin-RevId: bbf70f1fe1cb0e7fb80bcc72ca0b161452a36f58
`withKernel` method attaches current coroutine to core `kernelCoroutineScope`
If current coroutine is finished with an exception, the cancellation is propagated to the parent job.
This cancels `kernelCoroutineScope` and prevents further usage of the scope. The scope is never recreated, so it becomes impossible to use Rhizome after that.
As a solution, `kernelCoroutineScope` should be a supervisor to avoid it being canceled by children.
We can do that by creating `childScope` under the root scope.
GitOrigin-RevId: fc38d086f4f5b51538ce1173a25d457e1935bb1d
Provide CoroutineScope instead of CoroutineContext in KernelService to ensure that services which use Kernel will depend on this scope.
GitOrigin-RevId: b33a4a059dce0ac0669f7192b2fcefd6d3963858
When `ProjectEntity` is deleted with `LocalProjectEntity` all its data stored inside `Novelty` which represents the difference between two DB snapshots (before and after the change).
Therefore, `Project` has an active reference which doesn't allow it to be collected by GC.
`testProjectLeak` checks that all project instances are collected and it fails.
The workaround here is to invoke another change after removing the project entity, which will replace the old `Novelty` with a new one, thus removing the active reference to a project.
GitOrigin-RevId: eafde042b865c503958ec7c2e73a5c056f944ac7
This module is a core component of Rhizome - it's required for any interaction with Rhizome DB, creating entities, etc.
It was a V2 plugin as we wanted to make sure that only new V2 plugins will be able to use this.
We expected that it won't be much of a struggle, considering that every feature that would want to use Rhizome is going to be split into shared/backend/frontend modules (which could be V2 from the start).
However, we faced the issue that it's not possible to move some public API to V2 modules because it breaks backward compatibility, and therefore this API cannot depend on V2 module.
The first such issue was rewriting the progresses on Rhizome (RDCT-1444).
It's possible to create some interlayers to make it work without breaking compatibility and keeping kernel V2, but it was decided that it isn't worth it in such cases.
GitOrigin-RevId: 0488ca905bd145b2c3b6b2fa8481fa59b9f76529
