katelyn martin

Hello! Thank you for opening an issue about this. Fine grained cache control API's for Compute@Edge is something that we are currently working on, with great urgency. While I cannot...

~~i pushed an (_identical_) ammended commit, hoping to try re-running CI. i don't see anything in particular about these changes that would lead to the linker errors [observed](https://github.com/rust-rocksdb/rust-rocksdb/actions/runs/9071307884) in CI.~~...

the issues appear to be related to the `trybuild` snapshot tests. there's an unfortunate interaction between the build script and cargo's test runner, i'm debugging further over in cratelyn/rust-rocksdb#2.

i'm going to close this. #354 is a pre-existing rework of the build logic that this would conflict with, and for my personal use-case, linking against a pre-compiled version of...

:point_up: As you can see, I've just filed a patch upstream for this! More updates to come.

exciting news, the wasmtime pr has been merged. once there is a new release, we should be able to update our wasmtime dependency and address this! :tada:

> @cratelyn I've bumped wasmtime and cranelift-entity and switched to doing `use cranelift_entity::entity_impl` but still get this error in `entity.rs` for each of the types: > > ``` > Viceroy...

Restating some previous discussion below, for posterity: --- > My instinct here is that end users shouldn't need to trace hyper/tokio events unless there's a bug in Viceroy, and that...

> Could you also share your test? Is it necessary to `wait`? The docs are different. hello @StarpTech :wave: could you possibly try running your tests again with a call...

...and after a bit more digging, i believe i've reproduced your problem and produced a fix. the short summary of this is that after `ViceroyCtx::handle_request` finishes, these "dangling" async requests...