-
Notifications
You must be signed in to change notification settings - Fork 324
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing imports sometimes result in very confusing error trace #6092
Comments
Apparently, the following patch seems to fix the issue that is present on the linked branch: Index: distribution/lib/Standard/Database/0.0.0-dev/src/Internal/Redshift/Redshift_Dialect.enso
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/distribution/lib/Standard/Database/0.0.0-dev/src/Internal/Redshift/Redshift_Dialect.enso b/distribution/lib/Standard/Database/0.0.0-dev/src/Internal/Redshift/Redshift_Dialect.enso
--- a/distribution/lib/Standard/Database/0.0.0-dev/src/Internal/Redshift/Redshift_Dialect.enso (revision f6f7aa541f6d7e47c8af6c7a1760bd28e383f22a)
+++ b/distribution/lib/Standard/Database/0.0.0-dev/src/Internal/Redshift/Redshift_Dialect.enso (date 1679937196832)
@@ -17,8 +17,9 @@
import project.Internal.IR.Query.Query
import project.Internal.Postgres.Postgres_Dialect
import project.Internal.Common.Database_Join_Helper
-import project.Internal.SQL_Type_Mapping.SQL_Type_Mapping
import project.Internal.Postgres.Postgres_Type_Mapping.Postgres_Type_Mapping
+import project.Internal.SQL_Type_Mapping.SQL_Type_Mapping
+import project.Internal.Statement_Setter.Statement_Setter
from project.Errors import Unsupported_Database_Operation
## PRIVATE So it seems the issue has something to do with imports. Applying this patch and rebuiliding with Once I revert this mentioned patch, and rebuild again with |
@jdunkerley @hubertp could you confirm if you can repro the issue using the steps I listed above? It is very brittle so I want to check if I provided all necessary details. I manage to consistently reproduce it on my machine, but I'm not sure if that is enough. |
@radeusgd can't reproduce w/ or w/o caches using the provided instructions. |
Also, if I was to bet, I suspect it could have something to do with outdated caches of IRs/bindings. |
I was eventually able to confirm. And yes, it seems to be cache-related. If there is an error when generating the local caches, like missing import, it seems to be silent. As a result, having a partial cache and an existing source code, leads to rather obscure error message. |
`--compile` command would run the compilation pipeline but silently omit any encountered errors, thus skipping the serialization. This maybe was a good idea in the past but it was problematic now that we generate indexes on build time. This resulted in rather obscure errors (#6092) for modules that were missing their caches. Making compilation more resilient to sudden cache misses is a separate item.
`--compile` command would run the compilation pipeline but silently omit any encountered errors, thus skipping the serialization. This maybe was a good idea in the past but it was problematic now that we generate indexes on build time. This resulted in rather obscure errors (#6092) for modules that were missing their caches. Making compilation more resilient to sudden cache misses is a separate item.
`--compile` command would run the compilation pipeline but silently omit any encountered errors, thus skipping the serialization. This maybe was a good idea in the past but it was problematic now that we generate indexes on build time. This resulted in rather obscure errors (#6092) for modules that were missing their caches. Making compilation more resilient to sudden cache misses is a separate item.
`--compile` command would run the compilation pipeline but silently omit any encountered errors, thus skipping the serialization. This maybe was a good idea in the past but it was problematic now that we generate indexes on build time. This resulted in rather obscure errors (#6092) for modules that were missing their caches. Making compilation more resilient to sudden cache misses is a separate item.
Hubert Plociniczak reports a new STANDUP for yesterday (2023-03-28): Progress: More investigation into reported issues. Added more debug info 6099 in the absence of steps to reproduce. Struggled to reproduce 6092 but eventually got it. One problem is that we silently dropping errors during cache generation. The other is that we should be able to recover from caching issues. It should be finished by 2023-03-29. Next Day: Next day I will be working on the #6092 task. Provide a workaround for reporting errors. Catch up on the final design of execution contexts. |
Hubert Plociniczak reports a new STANDUP for today (2023-03-29): Progress: Added a workaround for reporting errors. Started to look into caches when dealing with broken caches. Filed 6135 as a follow up, since it will take a bit more time to get right and it is not the most pressing issue anymore. Meetings on execution contexts, scheduled tickets with follow up work. Started working on 6129 by replacing IOEnvironment with contexts. It should be finished by 2023-03-29. Next Day: Next day I will be working on the #6129 task. Continue implementing the changes according to the design. |
`--compile` command would run the compilation pipeline but silently omit any encountered errors, thus skipping the serialization. This maybe was a good idea in the past but it was problematic now that we generate indexes on build time. This resulted in rather obscure errors (#6092) for modules that were missing their caches. The change should significantly improve developers' experience when working on stdlib. # Important Notes Making compilation more resilient to sudden cache misses is a separate item to be worked on.
The mentioned bug seems a bit random and very hard to track down, I did not manage to find a small self-contained repro.
But it's been causing problems to me and @jdunkerley quite a lot in the recent weeks, in quite random moments.
The issue is that sometimes when running the project, we get a wall of errors saying that some names/types could not be found, for example:
But this often refers to pretty standard types like
Text
andNothing
which surely are imported in this file!To reproduce it:
wip/radeusgd/checkpoint-import-bug-repro
,sbt buildEngineDistribution
tests\Table_Tests\src\Database\Commpon_Spec.enso
.Other repros are quite possible, but this bug is very brittle and random. The steps above are ones that allowed me to reproduce the issue consistently.
The text was updated successfully, but these errors were encountered: