This PR introduces UUIDv7 implementations in both Python and SQL to establish the foundation for migrating from UUIDv4 to UUIDv7 as proposed in #19754.
ID generation algorithm of existing models are not changed, and new models should use UUIDv7 for ID generation.
Close#19754.
This PR introduces UUIDv7 implementations in both Python and SQL to establish the foundation for migrating from UUIDv4 to UUIDv7 as proposed in #19754.
ID generation algorithm of existing models are not changed, and new models should use UUIDv7 for ID generation.
Close#19754.
refactor(api): Separate SegmentType for Integer/Float to Enable Pydantic Serialization (#22025)
This PR addresses serialization issues in the VariablePool model by separating the `value_type` tags for `IntegerSegment`/`FloatSegment` and `IntegerVariable`/`FloatVariable`. Previously, both Integer and Float types shared the same `SegmentType.NUMBER` tag, causing conflicts during serialization.
Key changes:
- Introduce distinct `value_type` tags for Integer and Float segments/variables
- Add `VariableUnion` and `SegmentUnion` types for proper type discrimination
- Leverage Pydantic's discriminated union feature for seamless serialization/deserialization
- Enable accurate serialization of data structures containing these types
Closes#22024.
refactor(api): Separate SegmentType for Integer/Float to Enable Pydantic Serialization (#22025)
This PR addresses serialization issues in the VariablePool model by separating the `value_type` tags for `IntegerSegment`/`FloatSegment` and `IntegerVariable`/`FloatVariable`. Previously, both Integer and Float types shared the same `SegmentType.NUMBER` tag, causing conflicts during serialization.
Key changes:
- Introduce distinct `value_type` tags for Integer and Float segments/variables
- Add `VariableUnion` and `SegmentUnion` types for proper type discrimination
- Leverage Pydantic's discriminated union feature for seamless serialization/deserialization
- Enable accurate serialization of data structures containing these types
Closes#22024.
The `BaseSession` class in the `core/mcp/session` package uses `ThreadPoolExecutor`
to run the receive loop but fails to properly clean up the executor and receiver
future, leading to potential thread leaks.
This PR addresses this issue by:
- Initializing `_executor` and `_receiver_future` attributes to `None` for proper cleanup checks
- Adding graceful shutdown with a 5-second timeout in the `__exit__` method
- Ensuring the ThreadPoolExecutor is properly shut down to prevent resource leaks
This fix prevents memory leaks and hanging threads in long-running scenarios where
multiple MCP sessions are created and destroyed.
Signed-off-by: neatguycoding <15627489+NeatGuyCoding@users.noreply.github.com>
Co-authored-by: QuantumGhost <obelisk.reg+git@gmail.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
The `BaseSession` class in the `core/mcp/session` package uses `ThreadPoolExecutor`
to run the receive loop but fails to properly clean up the executor and receiver
future, leading to potential thread leaks.
This PR addresses this issue by:
- Initializing `_executor` and `_receiver_future` attributes to `None` for proper cleanup checks
- Adding graceful shutdown with a 5-second timeout in the `__exit__` method
- Ensuring the ThreadPoolExecutor is properly shut down to prevent resource leaks
This fix prevents memory leaks and hanging threads in long-running scenarios where
multiple MCP sessions are created and destroyed.
Signed-off-by: neatguycoding <15627489+NeatGuyCoding@users.noreply.github.com>
Co-authored-by: QuantumGhost <obelisk.reg+git@gmail.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Kalo Chin