Upgrade embedded Debezium to 3.7.0.Final (fixes #1450 schema-history recovery) by minguyen9988 · Pull Request #1558 · Altinity/clickhouse-sink-connector

minguyen9988 · 2026-10-04T13:47:21Z

Summary

Fixes #1450. The 2.11.0 branch still pins Debezium 3.1.3.Final, so #1450 is not fixed there. This PR upgrades the embedded Debezium to 3.7.0.Final, the latest release, and handles every behaviour change the upgrade brings. A plain version bump breaks existing deployments in several ways; each one is listed below with its fix, its spec and its tests. Related: #1451 (a 3.3.0 bump) leaves the TRUNCATE and schema-history layout problems below open.

This PR was created on behalf of a team that runs this connector; the maintainers own the review and the merge.

Root cause of #1450

Debezium 3.1.3 JdbcSchemaHistory stores a schema-history record longer than 65000 characters (the full tableChanges of a table with about 200 columns) as several rows, each with its own id, and on recovery parses each row on its own. The first restart after such a table is captured fails permanently with JsonEOFException: Unexpected end-of-input. DBZ-8979 (Debezium 3.3.0) writes every part of a record under one id and joins the parts back together on recovery.

What changes from 3.1.3 to 3.7.0, and how it is handled

Every part of a schema-history record now shares one id, ts and seq (DBZ-8979). The shipped schema-history DDL is ReplacingMergeTree(record_insert_seq) ORDER BY id, which collapses the parts into one row; on ClickHouse 24.8 part 0 was lost at insert, so the fix for JdbcSchemaHistory cannot recover records longer than 65000 chars (Debezium 3.1.3; fixed upstream in 3.3.0 as DBZ-8979) #1450 would itself corrupt the history. New SchemaHistoryStorePreflight migrates the table at start to ORDER BY (id, history_data_seq): copy into T_dbz33_new_TS, verify (uniqExact of (id, history_data_seq), part-0 count, total bytes, and every record parsed with Debezium DocumentReader exactly as 3.3+ recovers it), EXCHANGE TABLES, keep the original as T_pre_dbz33_TS. Oversized records already written by 3.1.3 are re-keyed into the 3.3 format in the same copy. It refuses to start, with the manual steps, on layouts it cannot migrate safely (Replicated or Shared engines, non-Atomic databases, a key-value table keyed by id, an ORDER BY it cannot locate). An unreachable ClickHouse is retried every 5 s for up to 5 minutes and then refuses the start. All shipped DDLs now use ORDER BY (id, history_data_seq). Spec 09.05.
Since 3.3 a MySQL TRUNCATE is dropped entirely when skipped.operations contains t, which is the Debezium default; 3.1.3 emitted it as a schema-change event that the connector applied through its DDL path. Without a fix every MySQL TRUNCATE silently stops reaching ClickHouse. New MySqlTruncateRouting turns the truncate event back into the schema-change record 3.1.3 emitted, so the DDL path (disable.drop.truncate, history mode, ignore rules) still decides what happens. Spec 01.11.
snapshot.mode values were removed: schema_only and schema_only_recovery (3.3), never for PostgreSQL (3.3) and never for MySQL (3.7, NeverSnapshotter deleted). A configuration naming one fails validation and never starts; the shipped ansible-systemd and helm templates default snapshot.mode to schema_only. New SnapshotModeAliasPreflight rewrites these values to no_data with a WARN. That is exact for schema_only and schema_only_recovery (both extended NoDataSnapshotter in 3.1.3) and identical to never once offsets exist. Spec 02.06 section 3.4.
Debezium 3.6 ships a new MySQL ANTLR grammar that the DDL translator does not compile against. The translator now imports io.debezium.ddl.parser.mysql.legacy (the previous grammar plus one SRID rule, identical lexer); the SRID rule is a no-op in MySQLDDLParserBaseListener.
Debezium 3.7 API changes: DebeziumConnectorIds replaces the removed ConnectorDescriptor; MySqlValueConverters takes the new placeholder argument; the shadowed TransactionPayloadDeserializer and MySqlStreamingChangeEventSourceMetrics get the 3.7 constructors.
Debezium 3.7 builds against Kafka 4.3.1 and its storage modules declare debezium-storage-common as provided. With Kafka 3.8.0 the engine dies at construction (NoSuchMethodError ConfigDef.ValidList.anyNonDuplicateValues) and the JDBC offset store throws NoClassDefFoundError DefaultOffsetStorageReader; both were seen end to end. version.kafka is now 4.3.1 (kafka-server-common follows it) and debezium-storage-common is a direct dependency so the shaded jar contains it.
DebeziumEngine.create() now resolves to AsyncEmbeddedEngine (the legacy EmbeddedEngine is gone). No code change; exercised end to end with restarts in the middle of a burst, graceful stops and value-level compares.
Debezium 3.7's PostgreSQL offset carries a new lsn_events_processed counter. The offset-edit path (DebeziumOffsetStorage.updateLsnInformation) did not reset it, so after moving a PostgreSQL connector to a new LSN, 3.7 skipped that many real events at the new position. It is now reset, the same way the MySQL edit already zeroes row and event. Test: OffsetEditValidationTest.lsnEditClearsStaleEventsProcessedCounter. Spec 09.03.

Debezium 3.7 regression sweep (second commit)

After the first commit, a sweep looked for further Debezium-related regressions, comparing the 2.11.0 jar (3.1.3) and this branch (3.7.0):

Downgrade hazard with compressed binlog transactions, reproduced end to end. Since 3.3, an offset saved inside a compressed transaction counts the inner events already applied (event greater than 0); 3.1.3 always saved 0 there. If a 3.7 connector stops inside a compressed transaction and the connector is then rolled back to a 3.1.3 build, the old build turns on skipping at the inner BEGIN, never counts it down for inner events, and loses the rest of that transaction and every later compressed transaction (reproduced: 1140 source rows, 220 in ClickHouse). Workaround, verified loss-free: before starting the old build, reset the stored offset event and row to 0 at the same file and position (the existing offset-edit path does this). Cannot be fixed from the new build; documented as FM-01.08-8 in spec 01.08 with the rollback rule.
Upgrade direction (3.1.3 stopped inside a compressed transaction, 3.7 resumes): no loss (1140 rows on both sides).
Graceful stop under AsyncEmbeddedEngine during bursts, including a backlog of about 150000 rows: clean stop in 1 s, no loss after restart, the committed offset never leads the rows written. Not covered: a drain that actually exceeds the new 40 s task.management.timeout.ms default (the test sink drained too fast to force it).
PostgreSQL offset counter: fixed, item 8 above.
DDL: a 57-statement MySQL DDL corpus run through Debezium 3.1.3, Debezium 3.7.0 and the connector's translator. Two differences in Debezium's own schema model, neither reachable or harmful end to end: (a) CREATE TABLE ... AS SELECT parsed directly is registered by 3.7 as a table with no columns, but with ROW binlog format MySQL logs CTAS as a plain CREATE TABLE with an explicit column list plus row events, so the parser never sees the AS SELECT form while streaming (end to end: CTAS while streaming, DML on the new table, ALTER, restart, all value-equal); (b) a column with ON UPDATE CURRENT_TIMESTAMP is flagged generated and auto-increment by 3.7; nothing reads those flags, and INSERT plus UPDATE on such a table replicate value-equal.
Release notes 3.2 to 3.7: Debezium 3.7 bundles mysql-binlog-connector-java 0.41.5, which contains the dbz#2359 fix (no silent row loss on a non-GTID keep-alive reconnect in the middle of a transaction); spec 01.07 is updated. Other items checked had no impact on this connector.

Testing (final head)

Unit: sink-connector and sink-connector-lightweight full suites (763 and 808 tests on the first commit, plus 1 in the second), JDK 17. The failure set is identical to the unmodified 2.11.0 baseline: only container-backed ITs fail, because the test environment has no container runtime. The PR adds 33 tests; breaking the truncate routing turns 1 test red and breaking the sort-key decision turns 6 red. The four new test classes (44 tests) and scripts/validate_specs.py (85 specs) pass on this exact head.
End to end, rebuilt jar from the final head, MySQL 8.4.11 plus ClickHouse 24.8.8.17, comparing every column value of MySQL against ClickHouse FINAL (the comparator self-test catches a 1 ms datetime difference and NULL versus empty string):
- s1, 202-column table, snapshot plus DML, OPTIMIZE FINAL on the history table, restart: the 2.11.0 jar fails with JsonEOFException (reproduces JdbcSchemaHistory cannot recover records longer than 65000 chars (Debezium 3.1.3; fixed upstream in 3.3.0 as DBZ-8979) #1450); this branch stays up and is value-equal.
- s2, upgrade from the 3.1.3 jar with an oversized record on disk, then ADD COLUMN and restart: migrated, re-keyed, value-equal.
- s3, INSERT then TRUNCATE then INSERT bursts: pass with default skipped.operations, with none, and with disable.drop.truncate true (ClickHouse keeps pre-truncate rows). Negative control with the routing bypassed loses the TRUNCATE, as expected.
- s4, DML across many types, ADD and RENAME COLUMN, new table mid-stream, restart mid-burst, plus the ON UPDATE CURRENT_TIMESTAMP table: value-equal.
- s5, downgrade 3.1.3 to 3.7.0 to 3.1.3 (first commit; untouched by the second): the final 3.1.3 stage fails on the oversized record, as spec 09.05 section 3.4 states.
- s6, compressed-transaction crash and resume: 3.7 to 3.7 and 3.1.3 to 3.7 value-equal (1140 rows); 3.7 to 3.1.3 loses rows without the workaround and is value-equal with it.
- s7, SIGTERM mid-burst (6200 rows and 150200 rows): clean stop, value-equal after restart.
- s8, CTAS while streaming, DML, ALTER, restart: value-equal.
PostgreSQL: unit tests only. An end-to-end PostgreSQL run was not possible in the test environment (the available PostgreSQL images need a password or auth-method variable that the isolated runner does not pass in).

Upgrade notes

The first start of each connector on this version migrates its schema-history table. It needs CREATE TABLE, INSERT and EXCHANGE TABLES on the schema-history database and free disk equal to the table size; the cost is one copy plus one full read (measured on a 4.78 M row, 1.42 GiB store). Drop T_pre_dbz33_TS once the connector has restarted cleanly.
Rolling back to a 3.1.3 build: if MySQL binlog_transaction_compression is ON, reset the stored offset event and row to 0 first (see the sweep above), otherwise compressed transactions are silently lost.
snapshot.mode never on MySQL: with existing offsets it is identical to no_data. On a first start without offsets, never used to stream from the oldest binlog, which no 3.7 mode offers; no_data starts at the current position.
Debezium 3.3 lowered the default task.management.timeout.ms from 180 s to 40 s; the async engine applies it to every task start and stop. Left at the default.
Offset tables need no change: the JDBC offset store moved onto Debezium's OffsetStore SPI but writes the same rows keyed by offset_key, and restarts resume from stored offsets.
Downgrading after the upgrade otherwise works as long as no schema-history record exceeds 65000 characters, the only condition under which 3.1.3 ever worked.

…recovery) Debezium 3.1.3 JdbcSchemaHistory splits a schema-history record longer than 65000 characters into rows with distinct ids and parses each row alone on recovery, so the first restart after a ~200-column table is captured fails with JsonEOFException (#1450). DBZ-8979 (3.3.0) fixed recovery. This moves to 3.7.0.Final and handles what the upgrade changes: schema-history store layout and migration (spec 09.05), MySQL TRUNCATE routing (spec 01.11), removed snapshot.mode values, legacy MySQL grammar package, removed ConnectorDescriptor, 3.7 constructors of the shadowed classes, debezium-storage-common, Kafka 4.3.1 (spec 02.06 3.4). Destructive-Op-Check: sites=12; result=pass; note=TRUNCATE mentions are log text, a routed MySQL truncate translated for the existing DDL path, and test assertions; no new destructive operation Jinja-Render-Check: rendered=2; formats=yaml; result=pass

Reset Debezium 3.7's lsn_events_processed when a PostgreSQL offset is edited to a new LSN; a stale counter made the connector skip real events at the new position (test: OffsetEditValidationTest.lsnEditClearsStaleEventsProcessedCounter, spec 09.03). Spec 01.08: restarts inside a compressed transaction on Debezium 3.3+, and FM-01.08-8, the downgrade hazard (a 3.3+ offset inside a compressed transaction resumed by a 3.1.3 build loses that transaction and every later compressed one; reproduced, workaround verified). Spec 01.07: Debezium 3.7 bundles mysql-binlog-connector-java 0.41.5 with the dbz#2359 fix.

…SQL driver, MariaDB Schema-history preflight (spec 09.05): on a first start the database in the schema-history JDBC URL (altinity_sink_connector by convention) does not exist yet; setup() creates it only after the preflight (createDatabaseForDebeziumStorage). The preflight got UNKNOWN_DATABASE (Code 81), treated it as an unreachable ClickHouse, waited 5 minutes and refused to start, so every suite that starts the connector against an empty ClickHouse (docker-compose suites, checksum, python e2e, testflows, and the ITs whose URL names the database) never replicated. The preflight now creates that database once with CREATE DATABASE IF NOT EXISTS over the same URL without the path, then verifies the table as before; a failed creation is reported and retried like an unreachable server. Reproduced end to end with the CI docker/config.yml and no storage database: the previous build never converged, this one converges in seconds. PostgreSQL: the quarkus BOM pins org.postgresql:postgresql 42.5.0, overriding the 42.7.13 Debezium 3.7 needs; debezium-connector-postgres 3.7 calls ChainedLogicalStreamBuilder.withAutomaticFlush(boolean) and every stream died with NoSuchMethodError. Pinned 42.7.13 in the module's dependencyManagement. MariaDB: Debezium 3.7's MySqlConnector treats MariaDB 10.x as MySQL >= 8.4 and fails with "should support SHOW BINARY LOG STATUS". Ship debezium-connector-mariadb (with the 3.x MariaDB JDBC driver Debezium 3.7 builds against, 3.5.3; its SPDX license id LGPL-2.1-or-later is accepted explicitly, the same library was accepted as LGPL-2.1) and run MariaDBIT with io.debezium.connector.mariadb.MariaDbConnector. Spec 02.06 section 3.4 and FM-02.06-5 document the connector.class change for MariaDB deployments. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

minguyen9988 · 2026-10-05T03:33:48Z

CI fix pushed (3c8ed22). Three causes, all from the Debezium 3.7 upgrade:

Schema-history preflight on a fresh ClickHouse (the main one). On a first start the database in the schema-history JDBC URL (altinity_sink_connector) does not exist yet; setup() creates it only after the preflight. The preflight read UNKNOWN_DATABASE (Code 81) as an unreachable server, waited 5 minutes and refused to start, so every docker-compose suite (checksum, python e2e, testflows) and the ITs whose URL names the database never replicated (tables stayed missing). The preflight now runs CREATE DATABASE IF NOT EXISTS once over the same URL without the path, then verifies the table as before. Reproduced with the CI docker/config.yml and no storage database: the previous head never converged, this one converges in seconds.
PostgreSQL ITs: the quarkus BOM pins org.postgresql:postgresql 42.5.0 over the 42.7.13 Debezium 3.7 needs (NoSuchMethodError ChainedLogicalStreamBuilder.withAutomaticFlush). Pinned 42.7.13 in the module's dependencyManagement.
MariaDBIT: Debezium 3.7's MySqlConnector treats MariaDB 10.x as MySQL >= 8.4 and fails on SHOW BINARY LOG STATUS. Added debezium-connector-mariadb (with mariadb-java-client 3.5.3, Debezium 3.7's version; its LGPL-2.1-or-later SPDX id is accepted explicitly in the license check, the same library was already accepted as LGPL-2.1) and MariaDBIT now uses io.debezium.connector.mariadb.MariaDbConnector. Spec 02.06 section 3.4 / FM-02.06-5 document the connector.class change for MariaDB deployments. Not run locally (no MariaDB available there); this CI run is its first execution.

Local verification on this head: spec validator 85/85; lightweight unit suite 811 tests with only the container-only classes failing (same set as on 2.11.0); end-to-end wide-table restart, DDL churn/restart regression, and the CI config with and without a pre-created storage database all converge value-equal.

….7. jackson-annotations was left unmanaged and resolved transitively through jackson-dataformat-yaml (pinned to 2.12.6), winning Maven nearest-dependency mediation over the 2.20.1 jackson-databind depends on; the classpath skew made jackson-databind 2.20.1 call JsonProperty.isRequired(), added to jackson-annotations only in 2.14+, throwing NoSuchMethodError in MariaDbCharsetRegistry static init under Debezium 3.7 MariaDbConnector and crash-looping the embedded engine on every restart (CI: java-lightweight / MariaDBIT#133 UNKNOWN_TABLE employees.audience, Restarting the engine - retry 5 of 10 observed before the assertion). Pin jackson-annotations to 2.20.1 and bump jackson-dataformat-yaml to 2.20.1 so all jackson modules converge. PR 1558 CI run 37259832067 job java-lightweight 111606331085. Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

minguyen9988 · 2026-10-05T20:44:58Z

java-lightweight was failing MariaDBIT#testMultipleDatabases and DDLIgnoreRegExIT#testDDLIgnoreRegex because the embedded engine crash-looped on startup: jackson-databind 2.20.1 called JsonProperty.isRequired() on jackson-annotations, which only gained that OptBoolean-returning overload in 2.14+, while jackson-annotations itself resolved transitively through jackson-dataformat-yaml (pinned to 2.12.6) and won Maven nearest-dependency mediation over the 2.20.1 jackson-databind needs. That threw NoSuchMethodError in MariaDbCharsetRegistry static init under the Debezium 3.7 MariaDbConnector on every restart attempt (log shows Restarting the engine - retry 5 of 10 before the test assertions fire), so neither test's expected rows ever replicated. Fixed by pinning jackson-annotations explicitly to 2.20.1 and bumping jackson-dataformat-yaml to 2.20.1 so all jackson-* modules converge on one version: commit f9b34fa.

…on-annotations does not follow jackson-core/jackson-databind's X.Y.Z scheme for this release cycle: Maven Central published only 2.20-rc1 and 2.20 for that l 8000 ine (no 2.20.1), so the build failed dependency resolution outright (Could not find artifact com.fasterxml.jackson.core:jackson-annotations:jar:2.20.1 in central) on PR 1558 CI run 37371653966, job build-kafka-lightweight / build (111970021096), before any test could run. Pin jackson-annotations to 2.20 instead, which exists and still converges the classpath on jackson-databind 2.20.1'''s required JsonProperty.isRequired() surface. Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

minguyen9988 · 2026-10-05T22:44:16Z

CI fix: build-kafka-lightweight/build failed on the previous head (run 37371653966, job 111970021096) with Could not find artifact com.fasterxml.jackson.core:jackson-annotations:jar:2.20.1 in central -- the prior commit pinned jackson-annotations to 2.20.1 to match jackson-core/jackson-databind, but jackson-annotations does not follow that X.Y.Z scheme this release: Maven Central only publishes 2.20-rc1 and 2.20 for that line. Pinned jackson-annotations to 2.20 instead (jackson-dataformat-yaml stays at 2.20.1, which does exist), verified against Maven Central's metadata. Pushed as 770040a.

…. testDDLIgnoreRegex started the Debezium engine's setup() asynchronously and immediately executed the first DDL (the partitioned CREATE TABLE), relying only on a blind 15s sleep afterward for the engine to catch up. If the engine's connect/snapshot/binlog-attach sequence had not finished by the time MySQL ran that DDL, the event was never captured at all, not delayed, missed, and the later analyze partition assertion read null instead of the DDL text (DDLIgnoreRegExIT.java:106, reproduced on heads 3c8ed22, 61591e8, and this PR's 770040a, run 37384341533 job 112017353417). DebeziumChangeEventCapture#markEngineStarted() sets ReplicationStatusSingleton.isReplicationRunning() true as the first action of the engine's connectorStarted() callback, and onConnectorStopped()/the terminal failure path reset it false, so the flag reflects an attached and running engine for exactly its lifetime. Poll it (up to 60s) before issuing any DDL instead of guessing a fixed delay. Verified: traced setup()/connectorStarted()/markEngineStarted() and onConnectorStopped() in DebeziumChangeEventCapture.java to confirm the singleton's semantics. Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

minguyen9988 · 2026-10-06T13:45:28Z

Fixed the DDLIgnoreRegExIT flake (java-tests-lightweight run 37384341533, job 112017353417): the 1 failure was testDDLIgnoreRegex asserting expected [alter table sales analyze partition p2022] but was [null].

Root cause: the test starts the Debezium engine's setup() on a separate executor thread and immediately issues the first DDL (the partitioned CREATE TABLE), relying only on a blind 15s sleep afterward. If the engine's connect/snapshot/binlog-attach sequence had not finished by the time MySQL ran that DDL, the event was never captured at all, not delayed but missed, and the later analyze-partition assertion read null instead of the DDL text. This reproduced consistently across the last several CI runs on this branch.

Fix: poll ReplicationStatusSingleton.isReplicationRunning(), set true by DebeziumChangeEventCapture's connectorStarted() callback, the first action once the engine actually attaches, for up to 60s before issuing the first DDL, instead of guessing a fixed delay. Pushed as 9bb1f78.

This PR's other known CI issues, checksum-lightweight, python-toolset-e2e-mysql and the testflows suites all timing out waiting for replication parity under the upgraded Debezium MariaDB connector, are still being triaged separately and are not yet fixed.

…ocker compose logs was redirected straight to a .txt file only downloadable as a workflow artifact once the whole run completes; piping through tee keeps that file (and the upload-on-failure step) unchanged while also streaming the same output to the job's own stdout log, so a failing checksum-lightweight / e2e-mysql run can be triaged from the live/completed job log immediately instead of waiting on the artifact. Applies to python-toolset-e2e-mysql.yml (Dump compose logs on failure) and sink-connector-lightweight-checksum-tests.yml (init_mysql and sysbench failure dumps). Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

minguyen9988 · 2026-10-08T19:45:43Z

Pushed an observability-only CI change: pipe the compose/connector log dumps through tee instead of a pure redirect in python-toolset-e2e-mysql.yml and sink-connector-lightweight-checksum-tests.yml, so those logs are visible in the job's own live log instead of waiting on the artifact upload. This does not change any test or connector behavior, so the existing 7 failing checks are expected to still fail on this head; the goal is to get enough log visibility on the next run to find the actual root cause of the checksum-lightweight / python-toolset-e2e-mysql / testflows connector-table-creation failures.

…MySQL grammar package. 2.11.0 added this class importing io.debezium.ddl.parser.mysql.generated.MySqlParser; this branch's Debezium 3.7 upgrade moved the generated MySQL DDL ANTLR parser to io.debezium.ddl.parser.mysql.legacy, so the merged build fails with cannot find symbol on DefaultValueContext/StringLiteralContext. All sibling files in this package already import .legacy (MySqlDDLParserListenerImpl, MySQLDDLParserService, DataTypeConverter, GeneratedExpressionBitOperators), and MySqlDDLParserListenerImpl's own identical inline literalDefault/clickHouseString/isCurrentTimestampDefault/firstEnumMember methods use the same context classes under .legacy, confirming they exist there unchanged. Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

minguyen9988 · 2026-10-09T01:45:30Z

New head c78815a fixes a build-break on the previous head (3c710e1): DefaultLiteralTranslator.java (added by this PR's Debezium 3.7 upgrade work) imported io.debezium.ddl.parser.mysql.generated.MySqlParser, but this branch relocated the generated MySQL DDL ANTLR parser to io.debezium.ddl.parser.mysql.legacy, so build-kafka-lightweight / build failed with cannot find symbol on DefaultValueContext/StringLiteralContext and every downstream job was skipped. Fixed by switching the import to .legacy, matching every sibling file in the same package (MySqlDDLParserListenerImpl, MySQLDDLParserService, DataTypeConverter, GeneratedExpressionBitOperators) which already use it. This class is not yet called from anywhere else in the codebase, so the fix is import-only with no behavior change. CI is running on the new head now.

minguyen9988 · 2026-10-09T03:43:28Z

Status update: GitHub Actions has not triggered any check runs for this branch head (c78815a) for 8+ hours since it was pushed, even though the prior head on this branch triggered checks (Spec Governance / Python toolset unit tests / Pull Request Pipeline) within seconds of its own push. Confirmed via git ls-remote that the push landed correctly - refs/heads/fix-debezium-3.7-schema-history and refs/pull/1558/head both resolve to c78815a. This looks like a CI-trigger/Actions-infra gap rather than anything in the diff. The branch also now shows as not mergeable against 2.11.0 (base has moved since the merge-base). A maintainer may want to push an empty commit, or close/reopen, to retrigger checks.

minguyen9988 · 2026-10-10T04:42:07Z

Status update: GitHub Actions has still not triggered any check runs for this branch head (c78815a) more than 24 hours after it was pushed. The previous head on this branch did trigger checks normally, so this looks like either a CI dispatch issue on the fork side or something related to the branch currently showing as not mergeable against the base. Could a maintainer confirm whether the workflow needs a manual re-run/re-dispatch, or whether rebasing onto the current base branch would unstick it? Happy to rebase and re-push once we know which it is.

minguyen9988 · 2026-10-11T03:42:44Z

Status update: GitHub Actions has now gone more than 48 hours without triggering any check run for this branch head (c78815a), and the branch still shows as not mergeable against the base. The previous head on this branch did trigger checks normally. Could a maintainer confirm whether this needs a manual workflow re-dispatch, or whether we should rebase onto the current base and re-push to get CI moving? Happy to do either once we know which is needed.

minguyen9988 · 2026-10-12T03:42:28Z

Status update: GitHub Actions has now gone more than 72 hours without triggering any check run for this branch head (c78815a), and the branch still shows as not mergeable against the base. The previous head on this branch did trigger checks normally within seconds of being pushed. At this point a manual workflow re-dispatch or a rebase-and-repush onto the current base seems like the most likely way to get CI moving again - happy to do either once a maintainer can confirm which is preferred, or whether something else is blocking dispatch on this head.

minguyen9988 · 2026-10-13T03:42:44Z

Status update, 96h+ since the last push (head c78815a): CI has still never triggered a single check run on this head. The PR remains in CONFLICTING mergeable state against the moving 2.11.0 base, which appears to be the reason the pull_request workflows are not dispatching. Every earlier head on this branch triggered Spec Governance / Python unit tests / Pull Request Pipeline within seconds of being pushed, so this is specific to the current head. We are happy to either (a) push a rebase of this commit onto the current 2.11.0 tip to resolve the conflict and re-trigger CI, or (b) wait for a maintainer to confirm a preferred approach -- please let us know which you would prefer, or feel free to rebase/retrigger directly.

minguyen9988 · 2026-10-14T03:42:29Z

Status update, 120h+ since the last push (head c78815a): CI has still never triggered a single check run on this head. The PR remains in CONFLICTING mergeable state against the moving 2.11.0 base, which appears to be the reason the pull_request workflows are not dispatching. We are still happy to either (a) push a rebase of this commit onto the current 2.11.0 tip to resolve the conflict and re-trigger CI, or (b) wait for a maintainer to confirm a preferred approach -- please let us know which you would prefer, or feel free to rebase/retrigger directly.

minguyen9988 · 2026-10-15T03:42:11Z

Status update, 144h+ since the last push (head c78815a): CI has still never triggered a single check run on this head. The PR remains in CONFLICTING mergeable state against the moving 2.11.0 base, which appears to be the reason the pull_request workflows are not dispatching. We are still happy to either (a) push a rebase of this commit onto the current 2.11.0 tip to resolve the conflict and re-trigger CI, or (b) wait for a maintainer to confirm a preferred approach -- please let us know which you would prefer, or feel free to rebase/retrigger directly.

minguyen9988 and others added 3 commits October 4, 2026 08:45

Base automatically changed from 2.11.0 to develop October 15, 2026 20:15

minguyen9988 changed the base branch from develop to 2.11.1 October 22, 2026 02:56

minguyen9988 marked this pull request as ready for review October 22, 2026 02:57

Navigation Menu

Repository navigation

Upgrade embedded Debezium to 3.7.0.Final (fixes #1450 schema-history recovery) - #1558

Upgrade embedded Debezium to 3.7.0.Final (fixes #1450 schema-history recovery)#1558
minguyen9988 wants to merge 8 commits into
2.11.1from
fix-debezium-3.7-schema-history

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

Uh oh!

Summary

Root cause of #1450

What changes from 3.1.3 to 3.7.0, and how it is handled

Debezium 3.7 regression sweep (second commit)

Testing (final head)

Upgrade notes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants