Open hubertp opened 1 month ago
Encountered it yet again in https://github.com/enso-org/enso/actions/runs/10245645438/job/28392624237?pr=10733#step:7:2072 run
GitHubHybrid visual and textual functional programming. Contribute to enso-org/enso development by creating an account on GitHub.
This is confusing. It seems to suggest that the problem is with the test that should be pending?
This is confusing. It seems to suggest that the problem is with the test that should be pending?
What do you mean?
Do you mean the
INFO ide_ci::program::command: bash ℹ️ Java FFI: [6/6, 17ms]
INFO ide_ci::program::command: bash ℹ️ - [PENDING] should report missing method error on Java Arrays
INFO ide_ci::program::command: bash ℹ️ Reason: Failing due to #6609
above?
That is most likely not it - the test summary is written after each group has finished executing. So the Java FFI pending test has finished and is now summarized.
Now the failure most likely is happening in the next group that is being executed. We could try to do a debug run which prints which group is started to try to locate the cause - but I'm not sure if that'll help.
Another interesting instance of this error is at https://github.com/enso-org/enso/actions/runs/10264320295/job/28398095736?pr=10555#step:7:2118 . This time, there is mention of java.io.IOException
:
INFO ide_ci::program::command: bash ℹ️ java.io.IOException: No_Such_Method
GitHubHybrid visual and textual functional programming. Contribute to enso-org/enso development by creating an account on GitHub.
Finally.
It could be one of missing
, sample
, foobar
, baz
, nope
, into
, or ==
. Although the exception is printed after ==
.
NFO ide_ci::program::command: enso ⚠️ java.lang.RuntimeException: #10750 ==
INFO ide_ci::program::command: enso ⚠️ at org.enso.interpreter.runtime.builtin.Error.makeNoSuchMethod(Error.java:162)
INFO ide_ci::program::command: enso ⚠️ at org.enso.interpreter.node.callable.InvokeMethodNode.methodNotFound(InvokeMethodNode.java:286)
INFO ide_ci::program::command: enso ⚠️ at org.enso.interpreter.node.callable.InvokeMethodNode.doFunctionalDispatchUncachedSymbol(InvokeMethodNode.java:219)
INFO ide_ci::program::command: enso ⚠️ at org.enso.interpreter.node.callable.InvokeMethodNodeGen.execute(InvokeMethodNodeGen.java:226)
INFO ide_ci::program::command: enso ⚠️ at org.enso.interpreter.node.callable.InvokeCallableNode.invokeDynamicSymbol(InvokeCallableNode.java:276)
INFO ide_ci::program::command: enso ⚠️ at org.enso.interpreter.node.callable.InvokeCallableNodeGen.execute(InvokeCallableNodeGen.java:194)
INFO ide_ci::program::command: enso ⚠️ at org.enso.interpreter.node.callable.ApplicationNode.executeGeneric(ApplicationNode.java:97)
INFO ide_ci::program::command: enso ⚠️ at org.enso.interpreter.node.scope.AssignmentNodeGen.executeGeneric(AssignmentNodeGen.java:51)
INFO ide_ci::program::command: enso ⚠️ at org.enso.interpreter.node.callable.function.BlockNode.executeGeneric(BlockNode.java:52)
INFO ide_ci::program::command: enso ⚠️ at org.enso.interpreter.node.ClosureRootNode.execute(ClosureRootNode.java:85)
https://github.com/enso-org/enso/actions/runs/10348083887/job/28657599636?pr=10769#step:7:10627
GitHubHybrid visual and textual functional programming. Contribute to enso-org/enso development by creating an account on GitHub.
https://github.com/enso-org/enso/actions/runs/10358080199/job/28690409691?pr=10769#step:7:9333
Looks like this time it was ==
method of Error.type
Reviewed the No_Such_Method. It has the to_display_text
properly set up.
I'm guessing it is an issue in engine/runtime/src/main/java/org/enso/interpreter/runtime/error/PanicException.java
as to why the Java Exception is not showing the display text.
It looks like computeMessage
will attempt to call the to_display_text via the InteropLibrary and fall back to the type name if it doesn't exist.
In my PR I've been experimenting with one revert (https://github.com/enso-org/enso/pull/10769/commits/7bab8b89baac33a4496e17369c22b8570151e39b). While previously on that PR I would get sporadic failures, after applying the revert I had seen none. Note: I don't think this change is the sole culprit of this bug. I would say that it unmasks some deeper problem, like specialization order which is triggered non-deterministically.
Hubert haven't seen this one for a while. Let's consider it fixed.
https://github.com/enso-org/enso/actions/runs/10682796071/job/29609456166?pr=10960#step:7:3772
GitHubHybrid visual and textual functional programming. Contribute to enso-org/enso development by creating an account on GitHub.
And another https://github.com/enso-org/enso/actions/runs/10791389410/job/29928689658?pr=11032#step:7:1255
GitHubHybrid visual and textual functional programming. Contribute to enso-org/enso development by creating an account on GitHub.
The sporadic failure happens mostly on MacOS although it did appear for other OS as well.
Will simply return a non-zero code and a simple
No_Such_Method
message, without any context. The issue is not new and by looking at the past CI builds it has happened for the first time in https://github.com/enso-org/enso/actions/runs/9686658267/job/26729584788 (#10377 merge, unrelated).