Skip to content

Let the SQL surface tests report a MEOS error as JMEOS raises it - #68

Merged
estebanzimanyi merged 1 commit into
MobilityDB:mainfrom
estebanzimanyi:fix/leave-meos-setup-to-jmeos
Oct 5, 2026
Merged

estebanzimanyi merged 1 commit into
MobilityDB:mainfrom
estebanzimanyi:fix/leave-meos-setup-to-jmeos

Conversation

@estebanzimanyi

Copy link
Copy Markdown
Member

GeneratedSqlSurfaceTest and SqlSurfaceOverUdfSurfaceTest install no MEOS error handler and neither
initialise nor finalise MEOS: every GeneratedFunctions wrapper runs GeneratedFunctions.ensureReady()
first, which initialises MEOS once per process and installs MeosErrorHandler, and reads
MeosErrorHandler.checkError() after the call, which rethrows the error MEOS reported as a typed
MeosException. A handler installed over MeosErrorHandler records nothing, so a failed call answers
false or NULL, and meos_initialize() puts back MEOS's default handler, which ends the process; a
finalization frees the timezone and collation of the thread that ensureReady() does not set up
again. Each test stops its Spark session after its tests.

Measured against MobilityDB master c435dc7863, the catalog of MEOS-API 993b4dbacf and the jar of
JMEOS main bc444c92: the 34 tests pass and the build prints no warning.

Why: MEOS reports an error through the handler JMEOS installs, so a test leaves that handler in
place and receives the error as the exception it raises.

GeneratedSqlSurfaceTest and SqlSurfaceOverUdfSurfaceTest install no MEOS error handler and neither
initialise nor finalise MEOS: every GeneratedFunctions wrapper runs GeneratedFunctions.ensureReady()
first, which initialises MEOS once per process and installs MeosErrorHandler, and reads
MeosErrorHandler.checkError() after the call, which rethrows the error MEOS reported as a typed
MeosException. A handler installed over MeosErrorHandler records nothing, so a failed call answers
false or NULL, and meos_initialize() puts back MEOS's default handler, which ends the process; a
finalization frees the timezone and collation of the thread that ensureReady() does not set up
again. Each test stops its Spark session after its tests.

Measured against MobilityDB master c435dc7863, the catalog of MEOS-API 993b4dbacf and the jar of
JMEOS main bc444c92: the 34 tests pass and the build prints no warning.

Why: MEOS reports an error through the handler JMEOS installs, so a test leaves that handler in
place and receives the error as the exception it raises.
@estebanzimanyi
estebanzimanyi merged commit 71065cd into MobilityDB:main Oct 5, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant