Skip to content

fix: prevent ora-21799 in ut_run()#1318

Closed
martin-bach-oracle wants to merge 1 commit into
utPLSQL:developfrom
martin-bach-oracle:fix-ora-21779
Closed

fix: prevent ora-21799 in ut_run()#1318
martin-bach-oracle wants to merge 1 commit into
utPLSQL:developfrom
martin-bach-oracle:fix-ora-21779

Conversation

@martin-bach-oracle

Copy link
Copy Markdown

This PR addresses the ORA-21799 duration not active error reported in https://forums.oracle.com/ords/apexds/post/ora-21779-duration-not-active-when-running-utplsql-on-23-26-4428

Initially I thought the error might be thrown during the transition to an autonomous transaction. The most suspicious spot in my investigation was crossing the autonomous boundary with object types in UT.RUN -> RUN_AUTONOMOUS (pragma autonomous_transaction) with a_reporter in out nocopy ut_reporter_base.

Turns out, that wasn't it. The RC appears earlier in the stack:

  • The stack trace shows a failure at startup event: UT_RUNNER line 93 triggers gc_initialize (ut_runner.pkb (line 93))
  • Event manager dispatches listener (ut_event_manager.pkb (line 70))
  • Reporter handler does treat(a_event_item as ut_run) on initialize (ut_reporter_base.tpb (line 171))

For gc_initialize, a_event_item is passed as NULL (no event object). My suspicion is that the ORA-21779 occurs on object-duration/type-cast handling at event dispatch time.

I tried passing a real object in UT_RUNNER line 93:

ut_event_manager.trigger_event(ut_event_manager.gc_initialize, ut_run());

If the treat(NULL as ut_run) is the problem, that should fix the issue. It works on my machine. Kindly review and merge if applicable.

@lwasylow

Copy link
Copy Markdown
Member

Hi @martin-bach-oracle
We have put a fix as part of #1310
Could you give it a shot using a develop source code branch?

@jgebal

jgebal commented Apr 21, 2026

Copy link
Copy Markdown
Member

Hi @martin-bach-oracle

We also faced the same issue recently and a fix is already merged into develop branch.
There was a comment about it here:
#1309 (comment)

The fix that we have applied can be found here:
https://github.com/utPLSQL/utPLSQL/pull/1310/changes#diff-5725a92b6cb359b9213a9b3390c253f930d04d9072f89c7bec1c6717aba48e07R168

I will prepare new intermediate release of utPLSQL framework, java-api and utPLSQL-cli, to give them a small refresh.

@martin-bach-oracle

Copy link
Copy Markdown
Author

Thanks for following up.

I'm not 100% sure now but I believe your fixes might still have thrown the error reported in the forum. Do you see any downside in changing line 93 in ut_runner?

@jgebal

jgebal commented Apr 22, 2026

Copy link
Copy Markdown
Member

I will investigate and let you know.

@jgebal

jgebal commented Apr 22, 2026

Copy link
Copy Markdown
Member

@martin-bach-oracle
I checked the utPLSQL code for all references to ut_event_manager.trigger_event
There are multiple instances where we internaly call ut_event_manager.trigger_event without the second parameter.
Passing an empty ut_run() object is more like a hack/workaround then a solution as empty ut_run() object does not represent the context of current utPLSQL test run that is executed.
In some cases that context is not relevant and not needed.
This is why the second arcument of the procedure ut_event_manager.trigger_event is optional and defaults to null.

In general, optional NULL argument is correct functionality but the behavior of this peice of code was unstable.
treat(a_event_item as ut_run)

Because it "sometimes fails" and "sometimes works" I consider it to be an oracle bug.

The workaround done by @lwasylow maintains the behavior (we still have NULL argument) so I would consider this a better option for now.

If that doesn't work, then the case statement needs to be changed to prevent treat(l_event_item as ut_run) alltogether in cases when l_event_item is NULL.

After the fix, every run of our pipeline on 23.26 AI was successful so I am expecting the workaround to be stable.

@lwasylow - do you have any insights into research you did and how you figured out that it's related to the fact that using the input argument variable as the problem?

@martin-bach-oracle

Copy link
Copy Markdown
Author

no worries, feel free to close the PR in that case

@jgebal

jgebal commented Apr 22, 2026

Copy link
Copy Markdown
Member

Thank you @martin-bach-oracle also for your feedback on oracle forum.

New releases should be available soon.

@jgebal jgebal closed this Apr 22, 2026
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.

3 participants