Skip to content

Conversation

@ChrisPenner
Copy link
Member

Overview

The current behaviour tries to map runtime references into codebase references when calling to get type info for them, but if the term is generated by the runtime, it will still call through with the intermediate/floating ref, which will always fail.

This isn't a big deal in UCM, but on Share each bogus ref triggers a DB call.

This changes it so we don't call through if there's no valid codebase ref for a runtime ref.

Implementation notes

  • Add new backref method which returns a Maybe instead.
  • Just return Nothing for the type lookup if we can't get a codebase ref for a runtime ref.

Interesting/controversial decisions

Nah

Test coverage

Existing tests show the runtime still behaves;
On Share I've tried out this build with debugging to ensure we're no longer calling through with bogus refs or cache misses :)

Loose ends

This should do it for now; I didn't see any other spots this would be a concern.

@ChrisPenner ChrisPenner requested review from aryairani and dolio July 29, 2025 17:35
@ChrisPenner ChrisPenner self-assigned this Jul 29, 2025
Copy link
Contributor

@dolio dolio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. Pretty straight forward.

@ChrisPenner
Copy link
Member Author

Hrmm, I'm not sure what's going on with CI:

Downloading index
Verification error: Invalid hash for <repo>/01-index.tar.gz
Downloading root
Waiting to acquire cache lock on /Users/runner/.stack/pantry/hackage/hackage-security-lock
Acquired cache lock on /Users/runner/.stack/pantry/hackage/hackage-security-lock
Released cache lock on /Users/runner/.stack/pantry/hackage/hackage-security-lock
Verification loop. Errors in order:
  Invalid hash for <repo>/01-index.tar.gz
  Invalid hash for <repo>/01-index.tar.gz
  Invalid hash for <repo>/01-index.tar.gz
  Invalid hash for <repo>/01-index.tar.gz
  Invalid hash for <repo>/01-index.tar.gz

I didn't change anything that should cause something like that 🤔

@aryairani
Copy link
Contributor

Hrmm, I'm not sure what's going on with CI:

Downloading index
Verification error: Invalid hash for <repo>/01-index.tar.gz
Downloading root
Waiting to acquire cache lock on /Users/runner/.stack/pantry/hackage/hackage-security-lock
Acquired cache lock on /Users/runner/.stack/pantry/hackage/hackage-security-lock
Released cache lock on /Users/runner/.stack/pantry/hackage/hackage-security-lock
Verification loop. Errors in order:
  Invalid hash for <repo>/01-index.tar.gz
  Invalid hash for <repo>/01-index.tar.gz
  Invalid hash for <repo>/01-index.tar.gz
  Invalid hash for <repo>/01-index.tar.gz
  Invalid hash for <repo>/01-index.tar.gz

I didn't change anything that should cause something like that 🤔

@ChrisPenner I've seen this before too, also not sure what the cause is but restarting the job seemed to fix it

@aryairani
Copy link
Contributor

This isn't a big deal in UCM, but on Share each bogus ref triggers a DB call.

Why isn't it an issue in UCM?

@aryairani aryairani merged commit a0a375a into trunk Jul 31, 2025
39 of 45 checks passed
@aryairani aryairani deleted the cp/filter-non-codebase-refs branch July 31, 2025 20:18
@ChrisPenner
Copy link
Member Author

ChrisPenner commented Aug 1, 2025

This isn't a big deal in UCM, but on Share each bogus ref triggers a DB call.

Why isn't it an issue in UCM?

In UCM it would still call out to SQLite in order to determine the ref doesn't exist, but the latency and round-trip time is much lower with SQLite than it is on Share.

@aryairani
Copy link
Contributor

This isn't a big deal in UCM, but on Share each bogus ref triggers a DB call.

Why isn't it an issue in UCM?

In UCM it would still call out to SQLite in order to determine the ref doesn't exist, but the latency and round-trip time is much lower with SQLite than it is on Share.

Got it, thanks.

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.

4 participants