Hi, first of all, thanks for the great tooling. We use it as a library in our tests. In our POC, we have observed an enormous build time in the Github Actions. Not sure, if it is related to Rust in general or if we can optimize it further.

Originally reported by @epolish https://github.com/fastly/cli/issues/419.

Summary:
When using the Fastly CLI it reports an error when trying to download a version of Viceroy for the Linux OS and 386 Arch. This is because there is no such build in the Viceroy release.

Thank you for building Viceroy, this is such a great project - I really really like that it is now possible to run Fastly code locally 🎉

I've been working on porting https://polyfill.io (a Fastly sponsored project) to be fully in Compute@Edge using the JavaScript SDK.

As of right now, due to the current lack of Edge Dictionary support in Viceroy (#11), I've inlined all the polyfills into the C@E code, this makes the bundled JavaScript file become 75.8 MB. After compiling the bundled JavaScript file into the Compute@Edge WASM file, it becomes 614 MB.

When trying to run this WASM file using Viceroy, an error is thrown:

Jul 31 20:33:53.927 ERROR memory index 0 has a minimum page size of 9469 which exceeds the limit of 2048

Is the limit of 2048 a hard limit of the Fastly Compute@Edge platform? Would it be possible to have this limit raised of be configurable within Viceroy?

Update: I cloned Viceroy and changed the minimum page size from 2,048 to 10,240, when running Viceroy with the wasm file it works and it used 620.6 MB of WebAssembly heap

Resolves https://github.com/fastly/Viceroy/issues/11

This reads a new section from the local_server part of fastly.toml named dictionaries.

The local_server.dictionaries section is an array of tables with two fields: name, and file.

The name field is a string which is used as the name of the dictionary and is used via the Dictionary.open method. This field uses the same validation rules asthe Fastly API (Name must start with alphabetical and contain only alphanumeric, underscore, and whitespace).

The file field is a string which is a file-path pointing to a JSON file which contains all the dictionary items within an object.

An example of a full local_server section of fastly.toml now looks like this:

[local_server]
  [local_server.backends]
    [local_server.backends.dog]
      url = "http://localhost:7878/dog-mocks"
  [local_server.dictionaries]
    [local_server.dictionaries.a]
      file="./a.json"
      format = "json"

Note for reviewers:

I couldn't figure out how the tests are implements for the wiggle abi parts such as lib/src/wiggle_abi/dictionary_impl.rs. I assume they are implemented in an internal/private repo that Fastly has?

• [X] Reading dictionaries from fasty.toml file
  • Note: I added the local dictionaries to the local_server section
• [x] Construct Dictionary and DictionaryHandles
  • [x] Dictionaries have two fields: name, and file
  • [x] Validate name field with Fastly' validation rules (Name must start with alphabetical and contain only alphanumeric, underscore, and whitespace)
  • [x] Validate file file (perhaps by doing a file existence check and checking it is JSON which adheres to our schema)
• [x] Implement Dictionary.open
• [x] Implement Dictionary.get
• [x] Tests
• [ ] documentation

This PR resolves #10 by adding support for mocked Geolocation responses. By default it will return the address of Fastly's HQ in San Francisco and users can override the response based on the requested IP address by modifying the fastly.toml file in the following manner:

[local_server]
	[local_server.geolocation]
                format = "inline-toml"
                [local_server.geolocation.addresses]
		[local_server.geolocation.addresses."127.0.0.1"]
			as_name = "Dummy, Inc."
			city = "New York"
			latitude = 1.23
			longitude = 1.23

or by providing it as an external resource:

[local_server]
	[local_server.geolocation]
                format = "json"
		file = "./test-geolocation-data.json"

test-geolocation-data.json:

{
    "127.0.0.1": {
        "as_name": "Fastly Test",
        "as_number": 12345,
        "area_code": 123,
        "city": "Test City",
        "conn_speed": "broadband",
        "conn_type": "wired",
        "continent": "NA",
        "country_code": "CA",
        "country_code3": "CAN",
        "country_name": "Canada",
        "latitude": 12.345,
        "longitude": 54.321,
        "metro_code": 0,
        "postal_code": "12345",
        "proxy_description": "?",
        "proxy_type": "?",
        "region": "CA-BC",
        "utc_offset": -700
    }
}

Current progress

• [X] support for mocked GeoIP responses
• [X] support for configuration through fastly.toml
• [X] support for IPv6 lookups
• [X] tests

During development, it's extremely convenient to have the service automatically reload on change. This is a tracking issue for implementing "watching" functionality.

Open Questions:

• It might make sense to have it be the default behavior, perhaps with the ability to explicitly disable it?
• Should Viceroy, or the Fastly CLI be responsible for watching files and reloading upon changes? How should the list of files to watch be specified, given that different languages must be supported? (cc: @Integralist)

Originally reported by @tschneidereit; cc: @aturon, @peterbourgon.

Fastly's UI provides stats on the total wall clock of a Compute@Edge program running in production. Viceroy should emit information about the wall clock duration of a single instance execution, so that users can reason about the behavior of their program in production.

• see also #77.
• see also #78.

Version

Fastly CLI version 1.5.0 (0d495f7)
Built with go version go1.17.6 linux/amd64
Viceroy version: viceroy 0.2.9

What happened

$ fastly compute serve --addr "127.0.0.1":7880 --skip-build
Initializing...
Fetching latest Viceroy release...
Running local server...

/home/cgutekunst/.config/fastly/viceroy: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /home/cgutekunst/.config/fastly/viceroy)

ERROR: error during execution process:

/home/cgutekunst/.config/fastly/viceroy: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /home/cgutekunst/.config/fastly/viceroy).

If you believe this error is the result of a bug, please file an issue: https://github.com/fastly/cli/issues/new?labels=bug&template=bug_report.md

System lsb:

DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=19.3
DISTRIB_CODENAME=tricia
DISTRIB_DESCRIPTION="Linux Mint 19.3 Tricia"

I'm guessing that the prebuilt (downloaded) version of Viceroy was built on Ubuntu 20; I'm on Mint 19.3, which is wrapper around Ubuntu 18.04 LTS.

WORKAROUND

Built viceroy from source and hard linked it from cargo/.bin to .config/fastly.

This commit adds the fastly_async_io hostcalls select and is_ready to Viceroy. Up to this point we only would do select for things like PendingRequest. Now we abstract over an AsyncItem which could be a PendingRequest, StreamingBody, or Body and you can call select over any of these async io operations. Most of this code is to accomodate these changes while maintaining the behavior of select for PendingRequest utilizing these new calls and creating the AsyncItem enum to hold all of these differing types in the same async_item map.

We also add an integration test similar to the C@E platform's to make sure that we implement the behavior correctly. With this we can be confident that select works the way we intend it too! As a bonus side effect of these changes we also add async support for hosts in our testing code in Viceroy which gives us some more flexibility in what we can accomplish or use!

In our test suite I have a few places I'd like to e.g. toggle some authentication logic based on environment variables.

This currently seems impossible, as Viceroy only exposes the environment variables it has predefined such as FASTLY_HOSTNAME, but it is not possible to set your own env variables and have them be accessible inside fastly compute serve

Hello, we run into

 panicked at 'not implemented: auto_decompress_response_set has not yet been implemented in Viceroy', /home/starptech/.cargo/registry/src/github.com-1ecc6299db9ec823/viceroy-lib-0.2.8/src/wiggle_abi/req_impl.rs:476:9

     // Build client request
        let req = hyper::Request::builder()
            .method(Method::POST)
            .uri("http://example.com")
            .header("authorization", "bearer 123")
            .header("content-type", "application/json")
            .body(Body::from(serde_json::to_string(client_json_body).unwrap()))
            .unwrap();

        // Fire request
        let response = viceroy::handle_request(req, url).await.unwrap();

when upgrading from "fastly: 0.8.0" to "fastly: 0.8.1"

It will internally update

[[package]]
name = "fastly-shared"
version = "0.8.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a50fae8c678779e8dcd18e36f9982d09c706764e8976c542fd53193a62d83727"
dependencies = [
 "bitflags",
 "http",
 "thiserror",
]

[[package]]
name = "fastly-sys"
version = "0.8.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "afcf0f870a0c9ac8166b0797a9391e5df81b7b5cc13b53b4d305e0b1368801d4"
dependencies = [
 "bitflags",
 "fastly-shared 0.8.1",
]

It was introduced in https://github.com/fastly/Viceroy/commit/fee8165aa6396a348b946a31bc658acb291e8594

Related: https://github.com/fastly/cli/issues/496

Bumps tokio from 1.21.2 to 1.23.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps tokio from 1.21.2 to 1.23.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

This is still a work in progress, but getting it up for some initial review on the general shape here. The goal is to allow developers of C@E services to use Viceroy to run unit tests that rely on things provided by Fastly's SDKs. This is based off of a proof-of-concept that @acfoltzer put together a few months ago.

how to use it

As a Rust developer, the only thing you need to do to use this is put the following in your project's .cargo/config:

[build]
target = "wasm32-wasi"

[target.wasm32-wasi]
runner = "{PATH_TO_VICEROY_BINARY} -C fastly.toml --test"

Then you can write tests that use the fastly crate a là:

#[test]
fn test_using_client_request() {
    let client_req = fastly::Request::from_client();
    assert_eq!(client_req.get_method(), Method::GET);
    assert_eq!(client_req.get_path(), "/");
}

#[test]
fn test_using_bodies() {
    let mut body1 = fastly::Body::new();
    body1.write_str("hello, ");
    let mut body2 = fastly::Body::new();
    body2.write_str("Viceroy!");
    body1.append(body2);
    let appended_str = body1.into_string();
    assert_eq!(appended_str, "hello, Viceroy!");
}

#[test]
fn test_a_handler_with_fastly_types() {
    let req = fastly::Request::get("http://example.com/Viceroy");
    let resp = some_handler(req).expect("request succeeds");
    assert_eq!(resp.get_content_type(), Some(TEXT_PLAIN_UTF_8));
    assert_eq!(resp.into_body_str(), "hello, /Viceroy!");
}

And run them with cargo test:

 % cargo test
   Compiling unit-tests-test v0.1.0 (/Users/rsinclair/src/fastly/test-runner-testing)
    Finished test [unoptimized + debuginfo] target(s) in 0.51s
     Running unittests src/main.rs (target/wasm32-wasi/debug/deps/unit_tests_test-11534a005cc5f600.wasm)
Using Viceroy to run tests...
running 3 tests
test tests::test_a_handler_with_fastly_types ... ok
test tests::test_using_bodies ... ok
test tests::test_using_client_request ... ok

test result: ok. 3 passed; 0 failed; 0 ignored

how it works

When you run cargo test, cargo produces a .wasm binary that contains all of your tests. By default, running this binary's _start function will execute all of your tests sequentially. Unfortunately when it runs into a test failure, it will panic and stop execution, preventing the rest of your tests from running. Fortunately, the binary produced by cargo test accepts arguments that allow us to control its execution in a more manageable way. To do that, this does the following:

1. Execute the binary with the --list argument. This will return a list of all the tests in the binary.
2. Execute the binary again with --list --ignored as arguments. This returns a list of just the ignored tests so we know which tests to ignore.
3. Set up a Session with placeholders for request, remote IP, and response channel that we can pass into the binary.
4. For each test in our list, execute the binary with the arguments --exact {test_name}. This will run only that test.
5. Record the resulting stdout and stderr.
6. Print out the test results in a format similar to cargo test's output

things that might be nice to have

• This doesn't allow the user to pass any additional arguments to cargo test (eg. cargo test specific_test_name or cargo test -- --no-capture).
• It's entirely sequential right now, but the test execution could be done in parallel
• a solution more generalizable to other language SDKs (related to the below)

things i'm still unsure about

• Do we want to support calls to backends in tests?
• How much of the environment in Fastly.toml should be set up for this execution mode?
• This is currently tied to being used in a very specific way by cargo test. Originally from chatting with @acfoltzer I had hoped to make this a more general execution mode that would simply set up the required state and naively run the provided binary's _start function. Unfortunately, querying the binary for the list of tests and running them one-by-one restricts this to only working with binaries produced by cargo test (or binaries with a very similar interface). I'm interested if anyone has ideas on how to get around that.
• If we go this route and decide to continue adding support for things like additional arguments, configurable number of threads, etc, we run into a problem where we are pretty much re-implementing large swaths of the default cargo test runner. As a small example, this already tries to mimic the output of cargo test. This seems unideal and I'm not sure what to do about that.

This introduces types and hostcalls for the Secret Store, and implements them in Viceroy, along with configuration to instantiate them.

In Compute@Edge, a Secret Store is an encrypted, read-only key-value store for sensitive data. In Viceroy, however, it is a simple unencrypted in-memory map defined in the fastly.toml file in a manner similar to Object Stores.

At a high level, a Wasm application using the APIs would:

1. Open a secret store by name
2. Get a secret from the store by name
3. Decrypt the secret by calling its plaintext method.

In Viceroy, Secret Stores are configured in the same way Object Stores are:

[local_server]
  [local_server.secret_store]
    store_one = [{key = "first", data = "This is some secret data"}, {key = "second", path = "/path/to/secret.json"}]

    [[local_server.secret_store.store_two]]
      key = "first"
      data = "This is also some secret data"

    [[local_server.secret_store.store_two]]
      key = "second"
      path = "/path/to/other/secret.json"

This PR is based off of #203 because it requires the 0.9.0-pre1 Rust SDK.

The main purpose of this PR was to support wasi-nn calls inside Viceroy. As the necessary changes weren't available until the wasmtime 3.0 release, I also made the updates to to make it compatible with the broader changes in that specific release.

The two big changes that came in were changes to the pattern for PoolingAllocationConfig and how error/traps are handled. There was also one minor change in that it looks like the linker is no longer under the tokio namespace.

In https://github.com/fastly/Viceroy/pull/188/, we found that Windows behaves differently than Unix-based platforms with respect to streaming bodies. In particular, the test tries to carefully construct a situation where we expect backpressure on a streaming body, and on Windows that backpressure seems to be cleared without either server or client side taking explicit action.

It's not clear whether this behavior difference stems from the client or the server side; in both cases we are using Hyper.