Skip to content

[KYUUBI #7389] Fix wrong parameter binding order in JDBCMetadataStore#transformMetadataState#7390

Closed
wangzhigang1999 wants to merge 1 commit intoapache:masterfrom
wangzhigang1999:fix/transformMetadataState-param-order
Closed

[KYUUBI #7389] Fix wrong parameter binding order in JDBCMetadataStore#transformMetadataState#7390
wangzhigang1999 wants to merge 1 commit intoapache:masterfrom
wangzhigang1999:fix/transformMetadataState-param-order

Conversation

@wangzhigang1999
Copy link
Copy Markdown
Contributor

@wangzhigang1999 wangzhigang1999 commented Apr 7, 2026

Closes #7389

The SQL placeholders expect (targetState, identifier, fromState) but the code passed (fromState, identifier, targetState), causing the UPDATE to set state back to fromState and match on targetState instead. This made cancelUnscheduledBatch silently fail.

Why are the changes needed?

In JDBCMetadataStore#transformMetadataState, the SQL is:

UPDATE metadata SET state = ? WHERE identifier = ? AND state = ?

The placeholders expect (targetState, identifier, fromState), but the code passes (fromState, identifier, targetState):

withUpdateCount(connection, query, fromState, identifier, targetState)

This causes cancelUnscheduledBatch("INITIALIZED" -> "CANCELED") to execute:

UPDATE metadata SET state = 'INITIALIZED' WHERE identifier = ? AND state = 'CANCELED'

Which matches no rows and silently returns false. The bug has existed since v1.8.0 ([KYUUBI #4790]).

How was this patch tested?

Added a unit test transformMetadataState should transition state correctly in JDBCMetadataStoreSuite that:

  1. Inserts a metadata record with state = "INITIALIZED"
  2. Calls transformMetadataState(id, "INITIALIZED", "CANCELED")
  3. Asserts the method returns true
  4. Asserts the persisted state is "CANCELED"

Was this patch authored or co-authored using generative AI tooling?

No.

…formMetadataState

The SQL placeholders expect (targetState, identifier, fromState) but
the code passed (fromState, identifier, targetState), causing the
UPDATE to set state back to fromState and match on targetState instead.
This made cancelUnscheduledBatch silently fail.
@pan3793
Copy link
Copy Markdown
Member

pan3793 commented Apr 9, 2026

a stupid mistake ... thanks for fixing

@pan3793 pan3793 added this to the v1.10.4 milestone Apr 9, 2026
@pan3793 pan3793 closed this in bb67bd6 Apr 9, 2026
pan3793 pushed a commit that referenced this pull request Apr 9, 2026
…#transformMetadataState

Closes #7389

The SQL placeholders expect (targetState, identifier, fromState) but the code passed (fromState, identifier, targetState), causing the UPDATE to set state back to fromState and match on targetState instead. This made cancelUnscheduledBatch silently fail.

### Why are the changes needed?

In `JDBCMetadataStore#transformMetadataState`, the SQL is:
```sql
UPDATE metadata SET state = ? WHERE identifier = ? AND state = ?
```
The placeholders expect `(targetState, identifier, fromState)`, but the code passes `(fromState, identifier, targetState)`:
```scala
withUpdateCount(connection, query, fromState, identifier, targetState)
```

This causes `cancelUnscheduledBatch("INITIALIZED" -> "CANCELED")` to execute:
```sql
UPDATE metadata SET state = 'INITIALIZED' WHERE identifier = ? AND state = 'CANCELED'
```
Which matches no rows and silently returns `false`. The bug has existed since v1.8.0 ([KYUUBI #4790]).

### How was this patch tested?

Added a unit test `transformMetadataState should transition state correctly` in `JDBCMetadataStoreSuite` that:
1. Inserts a metadata record with `state = "INITIALIZED"`
2. Calls `transformMetadataState(id, "INITIALIZED", "CANCELED")`
3. Asserts the method returns `true`
4. Asserts the persisted state is `"CANCELED"`

### Was this patch authored or co-authored using generative AI tooling?

No.

Closes #7390 from wangzhigang1999/fix/transformMetadataState-param-order.

Closes #7389

e3142a5 [wangzhigang] [KYUUBI] Fix wrong parameter binding order in JDBCMetadataStore#transformMetadataState

Authored-by: wangzhigang <wzg443064@alibaba-inc.com>
Signed-off-by: Cheng Pan <chengpan@apache.org>
(cherry picked from commit bb67bd6)
Signed-off-by: Cheng Pan <chengpan@apache.org>
pan3793 pushed a commit that referenced this pull request Apr 9, 2026
…#transformMetadataState

Closes #7389

The SQL placeholders expect (targetState, identifier, fromState) but the code passed (fromState, identifier, targetState), causing the UPDATE to set state back to fromState and match on targetState instead. This made cancelUnscheduledBatch silently fail.

### Why are the changes needed?

In `JDBCMetadataStore#transformMetadataState`, the SQL is:
```sql
UPDATE metadata SET state = ? WHERE identifier = ? AND state = ?
```
The placeholders expect `(targetState, identifier, fromState)`, but the code passes `(fromState, identifier, targetState)`:
```scala
withUpdateCount(connection, query, fromState, identifier, targetState)
```

This causes `cancelUnscheduledBatch("INITIALIZED" -> "CANCELED")` to execute:
```sql
UPDATE metadata SET state = 'INITIALIZED' WHERE identifier = ? AND state = 'CANCELED'
```
Which matches no rows and silently returns `false`. The bug has existed since v1.8.0 ([KYUUBI #4790]).

### How was this patch tested?

Added a unit test `transformMetadataState should transition state correctly` in `JDBCMetadataStoreSuite` that:
1. Inserts a metadata record with `state = "INITIALIZED"`
2. Calls `transformMetadataState(id, "INITIALIZED", "CANCELED")`
3. Asserts the method returns `true`
4. Asserts the persisted state is `"CANCELED"`

### Was this patch authored or co-authored using generative AI tooling?

No.

Closes #7390 from wangzhigang1999/fix/transformMetadataState-param-order.

Closes #7389

e3142a5 [wangzhigang] [KYUUBI] Fix wrong parameter binding order in JDBCMetadataStore#transformMetadataState

Authored-by: wangzhigang <wzg443064@alibaba-inc.com>
Signed-off-by: Cheng Pan <chengpan@apache.org>
(cherry picked from commit bb67bd6)
Signed-off-by: Cheng Pan <chengpan@apache.org>
@pan3793
Copy link
Copy Markdown
Member

pan3793 commented Apr 9, 2026

thanks, merged to master/1.11.2/1.10.4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug] Wrong parameter binding order in JDBCMetadataStore#transformMetadataState

2 participants