feat: Add async migrations - #470
Conversation
abe7dac to
c735e0e
Compare
|
@cursor review |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit c735e0e. Configure here.
c735e0e to
ec7746a
Compare
…ic base Drop _MigrationConfigBase and give MigrationConfig and AsyncMigrationConfig their own bodies. The shared base saved only a few trivial passthrough properties while adding generic indirection, and full duplication matches how Config/AsyncConfig are handled. MigrationConfig reverts to its pre-async standalone form.
| @@ -1,8 +1,15 @@ | |||
| # async_migrator is import-cheap (asyncio stdlib only, no aiohttp), so it is | |||
| _MigratorBuilderT = TypeVar('_MigratorBuilderT', bound='_MigratorBuilderBase') | ||
|
|
||
|
|
||
| class _MigratorBuilderBase: |
There was a problem hiding this comment.
I think the docs for the methods in this type will be missing from the API docs.
There isn't :interhited-members: set for the module. But I am not sure that adding that would be good either, or if you need a different approach.
|
|
||
| return authoritative_result | ||
|
|
||
| async def __write_both(self, authoritative: AsyncExecutor, nonauthoritative: AsyncExecutor, tracker: OpTracker) -> Tuple[OperationResult, Optional[OperationResult]]: |
There was a problem hiding this comment.
Do we have a standard approach we are using for task cancellation? I am concerned about cancelling between the writes potentially. I am not familiar enough with the ecosystem to know if we can just say not to do that.
Adds the async migration surface for the async Python SDK —
AsyncMigrator,AsyncMigratorBuilder,AsyncMigrationConfig, and theAsyncMigratorFntype — inldclient/migrations/async_migrator.py, eagerly exported fromldclient/migrations/__init__.py(import-cheap: asyncio stdlib only, no aiohttp).Also carries the migration config/builder dedup shared by the sync and async surfaces:
types.pygains_MigrationConfigBase[_MigratorFnT](Generic) and_MigratorBuilderBase(fluent-setter mixin), andmigrator.py'sMigratorBuilderis re-based onto that mixin. These are behavior-preserving refactors of already-released sync code.The public async classes carry experimental
.. caution::blocks.Self-contained: depends only on already-merged foundation work. The
AsyncLDClient/Contextreferences areTYPE_CHECKING-only (annotations kept lazy viafrom __future__ import annotations); no runtime import of any not-yet-merged async module.No CHANGELOG or version changes (handled at release).
Tracked internally: SDK-2767
Note
Medium Risk
New experimental dual-read/write migration paths can affect customer data routing when adopted; sync builder refactor is low-risk but touches released migration APIs.
Overview
Adds an experimental async migration API (
AsyncMigrator,AsyncMigratorBuilder,AsyncMigrationConfig,AsyncMigratorFn) that mirrors the sync migrator: flag-driven stages, old/new coroutine hooks, dual-read consistency checks, andtrack_migration_optelemetry. Reads can run in parallel viaasyncio.gather(vs threads on sync).Sync refactor: fluent builder options (
read_execution_order,track_latency,track_errors) move to_MigratorBuilderBaseintypes.py;MigratorBuildersubclasses it with unchanged behavior. New symbols are eagerly exported fromldclient.migrations(stdlib-only import path).Broad
test_async_migrator.pycoverage aligns with existing sync migrator tests (stages, tracking, execution order).Reviewed by Cursor Bugbot for commit 9de05e2. Bugbot is set up for automated code reviews on this repo. Configure here.