Skip to content
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

add some runtime type-checking in Image.env #2880

Merged
merged 3 commits into from
Feb 22, 2025
Merged

Conversation

thundergolfer
Copy link
Contributor

@thundergolfer thundergolfer commented Feb 19, 2025

Describe your changes

Action taken in response to user report: https://modal-com.slack.com/archives/C069RAH7X4M/p1739956895311459

But if feels a bit piecemeal? Don't really want to spread lots of runtime type-checking across the code just for the purposes of nicer error messages. Alternatively I've put up a docs change on the other repo (#20024)


Check these boxes or delete any item (or this section) if not relevant for this PR.

  • Client+Server: this change is compatible with old servers
  • Client forward compatibility: this change ensures client can accept data intended for later versions of itself

Note on protobuf: protobuf message changes in one place may have impact to
multiple entities (client, server, worker, database). See points above.


Copy link
Contributor

@mwaskom mwaskom left a comment

Choose a reason for hiding this comment

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

I think these sort of runtime type assertions have to feel piecemeal in Python, but adding one here makes sense as this is an easy mistake to make, and the current error message is not very interpretable.

Would be great to have a small unit test for this!

modal/image.py Outdated
Comment on lines 2019 to 2020
non_str_keys = [key for key, val in vars.items() if not isinstance(val, str)]
raise InvalidError(f"Environment variables must be strings. Invalid keys: {non_str_keys}")
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a reason you're deferring this till after catching a TypeError? One advantage to doing it immediately (i.e. not inside the build_dockerfile closure) is that the error will get attributed to the relevant line of user code; raising from the closure produces a very long and basically uninterpretable traceback.

I guess the downside is that code outside of the closure will execute on container cold starts which is undesirable. Shouldn't be too costly in most cases .... but every millisecond counts ;)

@thundergolfer thundergolfer merged commit 665c589 into main Feb 22, 2025
24 checks passed
@thundergolfer thundergolfer deleted the jonathon/image-env-ux branch February 22, 2025 06:26
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.

2 participants