fudianchn opened a new issue, #39846:
URL: https://github.com/apache/shardingsphere/issues/39846

   AI disclosure: this issue was prepared with AI coding agents, reviewed and 
revised line by line by me.
   
   ## Bug Report
   
   ### Which version of ShardingSphere did you use?
   
   Current master, heads from `bf953abc` (2026-09-06) to `fd405e59` 
(2026-09-14).
   
   ### Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy?
   
   ShardingSphere-Proxy in cluster mode (ZooKeeper) with openGauss 3.1.0 
storage, found in the `E2E - pipeline on opengauss/opengauss:3.1.0` job of 
`test/e2e/operation/pipeline`.
   
   ### Expected behavior
   
   The job runs green as before 2026-09-13 23:30 UTC (nightlies of 09-10 and 
09-11 passed). If reloading a just-created table returns nothing, the failure 
should surface as a diagnosable error instead of an NPE.
   
   ### Actual behavior
   
   Since 2026-09-13 23:33 UTC every execution of this job has failed: 10 PR 
runs on unrelated branches (`bumpgraalvm`, `dev`, `pipeline-1` and others, 
links below) plus the 2026-09-14 nightly on `fd405e59`, where this is the only 
failed job. Green PR runs in the window did not execute this job at all.
   
   `CDCE2EIT.assertCDCDataImportSuccess` fails at `initSchemaAndTable` while 
creating `t_order` through the proxy. The client receives `ERROR: Unknown 
exception`, and the proxy log shows:
   
   ```
   java.lang.NullPointerException: Cannot invoke 
"org.apache.shardingsphere.infra.metadata.database.schema.model.ShardingSphereTable.getName()"
 because "each" is null
       at 
org.apache.shardingsphere.mode.metadata.persist.metadata.service.TableMetaDataPersistService.persist(TableMetaDataPersistService.java:95)
       at 
org.apache.shardingsphere.mode.manager.cluster.persist.service.ClusterMetaDataManagerPersistService.createTable(ClusterMetaDataManagerPersistService.java:117)
       at 
org.apache.shardingsphere.mode.metadata.refresher.pushdown.type.table.CreateTablePushDownMetaDataRefresher.refresh(CreateTablePushDownMetaDataRefresher.java:53)
       at 
org.apache.shardingsphere.mode.metadata.refresher.pushdown.PushDownMetaDataRefreshEngine.refresh(PushDownMetaDataRefreshEngine.java:94)
       at 
org.apache.shardingsphere.proxy.backend.connector.StandardDatabaseProxyConnector.doExecute(StandardDatabaseProxyConnector.java:243)
       at 
org.apache.shardingsphere.proxy.frontend.postgresql.command.query.extended.Portal.bind(Portal.java:112)
       ...
   ```
   
   In the same run `PostgreSQLMigrationGeneralE2EIT` stays in preparation and 
its job status records contain the same NPE as error message. The stack above 
is from the PR #39613 run; the NPE message is identical in the nightly and the 
first failing PR run I checked.
   
   ### Reason analyze (If you can)
   
   `TableMetaDataRefresherLoader.loadCreatedTable` reloads the table through 
`GenericSchemaBuilder.build` with `fallbackWhenMissing=false`, so it returns 
null when the rebuilt schema does not contain the just-created table. 
`CreateTablePushDownMetaDataRefresher` passes that result to `createTable` 
without a null check, `ClusterMetaDataManagerPersistService.createTable` wraps 
it in `Collections.singleton(table)`, and `TableMetaDataPersistService.persist` 
then calls `each.getName()` on the null element. The pushdown refresher path 
was introduced in #39612.
   
   Why the rebuild started missing the table on 2026-09-13 23:30 UTC is 
unclear. My branch is frozen since 2026-09-10, the job passed on it on 09-10 
and failed on 09-15 with the same stack, which points to an environmental 
trigger rather than a specific commit.
   
   A null check in `CreateTablePushDownMetaDataRefresher` that skips persisting 
or throws an error naming the missed table would turn this into something 
diagnosable.
   
   ### Steps to reproduce the behavior, such as: SQL to execute, sharding rule 
configuration, when exception occur etc.
   
   1. Run the `E2E - Operation` workflow on any current branch.
   2. The `E2E - pipeline on opengauss/opengauss:3.1.0` job fails in 
`CDCE2EIT.assertCDCDataImportSuccess` while executing the `t_order` CREATE 
TABLE of `IntPkLargeOrderDAO` through the proxy.
   
   I have no local reproduction; the evidence is the linked CI runs.
   
   ### Example codes for reproduce this issue (such as a github link).
   
   - Failing job on PR #39613 (2026-09-15): 
https://github.com/apache/shardingsphere/actions/runs/34922545593/job/104234725680
   - First failing run on unrelated branch `bumpgraalvm` (2026-09-13 23:33 
UTC): https://github.com/apache/shardingsphere/actions/runs/34790055391
   - Failing nightly on master `fd405e59` (2026-09-14): 
https://github.com/apache/shardingsphere/actions/runs/34884324946/job/104112883020
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: 
[email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to