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

feat: when deserialization of module from filesystem cache fails, remove from cache #138

Open
wants to merge 1 commit into
base: feat/rm-serialized-module-cache
Choose a base branch
from

Conversation

mattyg
Copy link
Member

@mattyg mattyg commented Dec 24, 2024

Resolves #137

Merging into feat/rm-serialized-module-cache for a clean diff.

I'm not sure if this is the right approach, so let me know if you think differently.

/// Wasmer failed to serialize a Module to bytes.
ModuleSerialize(String),
/// Wasmer failed to deserialize a Module from bytes.
ModuleDeserialize(String),
Copy link
Member Author

Choose a reason for hiding this comment

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

Additional error types for clarity

let module = match module_result {
Ok(d) => Ok(Arc::new(d)),
Err(e) => {
let _ = self.remove_from_filesystem_cache(key);
Copy link
Member Author

Choose a reason for hiding this comment

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

Remove from cache, but ignore any errors deleting the file (i.e. if it doesn't exist or user doesn't have permissions). Not sure if the error should be passed up.


// Module cannot be retrieved from fs cache
let res = module_cache.get(key, &wasm);
assert!(res.is_err());
Copy link
Member Author

Choose a reason for hiding this comment

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

Getting a corrupt file from the filesystem cache errors.


// 2nd time, module can be retrieved from cache
let res = module_cache.get(key, &wasm).unwrap();
assert_eq!(*res.serialize().unwrap(), *serialized_module);
Copy link
Member Author

@mattyg mattyg Dec 24, 2024

Choose a reason for hiding this comment

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

After getting a corrupt file from the filesystem cache, it is removed from the filesystem, so the next get succeeds.

I'm not sure if a better approach would be to (1) remove it from the filesystem then (2) retry the get once, so the caller does not need to call get twice.

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.

1 participant