Repository navigation
[Misc] Add generic extension points to reduce cross-branch conflicts - #18683
Conversation
…a ConfigManagerContext
# Conflicts: # iotdb-core/confignode/src/main/java/org/apache/iotdb/confignode/consensus/request/ConfigPhysicalPlanType.java
JackieTien97
left a comment
JackieTien97
left a comment
There was a problem hiding this comment.
Requesting changes for two compatibility regressions in existing Pipe paths: V3 auth snapshots sent to older receivers, and mixed-table InsertRows forwarded as single requests.
Validation: 72 focused unit tests passed, with additional new/old profile-reader, procedure-serialization and information-schema SPI probes. The findings were reproduced using real serialization and request/reader code; a complete cross-version two-cluster run was not performed.
| // Now it's version 1 | ||
| protected static final int VERSION = 2; | ||
| // Version 3 appends an extra segment region after the RBAC privileges. | ||
| protected static final int VERSION = 3; |
There was a problem hiding this comment.
[P1] Preserve the legacy profile format for older Pipe receivers
The default writer now emits V3 even when no extension segment is present, while auth snapshots are still transferred verbatim using the existing ConfigSnapshot protocol. If the sender is upgraded before its Pipe receiver, the receiver's old CNPhysicalPlanGenerator consumes the two session fields only for tag == 2, so it misreads V3's default -1/-1 session limits as privilege data. An independently compiled pre-PR reader produced 13 extra GrantUser plans, all with grant option, for the same unprivileged user whose V2 profile produced none. Please retain the complete V2 format when extensions are unused, or negotiate/transcode the profile format before sending it to an older receiver.
| if (!fromPipeBatch) { | ||
| return rowStatements.isEmpty() | ||
| ? Collections.emptySet() | ||
| : Collections.singleton(resolveTargetTable(rowStatements.get(0), context)); |
There was a problem hiding this comment.
[P2] Validate every table in single-request Pipe row plans
An unmarked InsertRows is not necessarily single-table. Pipe batching before #18577 grouped rows only by database and could create a legitimate table1/table2/table1 plan; with sink.batch.enable=false, a cascading Pipe forwards that original InsertNode as one V2 request. The single-request decoder does not set fromPipeBatch, so this branch checks only table1, although subsequent schema/device validation still processes every row. A probe using the real serialization and request constructor checked both tables on the merge base but only table1 here; a normal rejection for table2 was skipped and schema validation was entered. Please retain all-row target deduplication, or maintain the invariant through every producer and rebuilder, including single/binary transfers.
|
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #18683 +/- ##
============================================
- Coverage 45.57% 45.52% -0.05%
Complexity 712 712
============================================
Files 5483 5496 +13
Lines 396291 396642 +351
Branches 51567 51608 +41
============================================
- Hits 180590 180582 -8
- Misses 215701 216060 +359 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
2 participants
This PR bundles a set of small, self-contained and behavior-preserving changes that are introduced ahead of time so that long-lived feature branches do not conflict with master. It only adds extension points / placeholders and does not change existing behavior.
No behavior change for existing statements; the new extension points and reserved identifiers are inert until a feature uses them.