Named pipe support has been merged in tokio . Scrap use of our own fork and use the official one instead. See https://github.com/tokio-rs/tokio/blob/master/examples/named-pipe.rs and https://docs.rs/tokio/1.12.0/tokio/net/windows/named_pipe/struct.NamedPipeServer.html.

Acceptance Criteria

• Any potentially breaking change forces and update to major version.
  • Deleting an input or output
  • changing and input or output type (if they can’t be connected any more)
  • changing execution environment

Other changes should result in either a minor version or a patch version

• if checksum of the code is equal and tags are equal (and everything else is equal) reject it?

Currently we add the bare computer name and localhost as alt names. It should also have the fully qualified name, i.e: <name>.<domain>, in case people use that to connect.

Currently the function folder is free form. Instead it should be a context object of some sort with support for

• One folder for this particular execution
• A shared space that can be used as a cache for downloaded attachments and other things

message Filters {
...
uint32 offset = 3;
uint32 limit = 4;
...
}

They should be uint64 since we use it as an usize.

• Just change the fields in firm/protocols/functions/functions.proto.
• Make sure the updated type compiles on all projects that depend on the proto type.

Currently, the token cache is written to a JSON file to disk. This is a reasonable fallback but as a first option we should try to use a system credential store if there is one (on Windows there always is for example).

Currently we only provide the auth method when uploading attachment, not when downloading. They might also not be the same ofc.

There is really no point in having them as separate libraries. Moving test_macros to firm-types means one less dependency to care about.

On some places we define test functions like the following.

#[test]
fn test_something()

"test" in the beginning of the function name is redundant. Remove it.

An example we have today when we deploy "new" functions where we first register and upload attachments before checking if we can actually register the function. This means we upload orphaned attachments just because function registry fails.

We must always check if the function exists but we need a flag to decide what to do in case it finds an already registered function.

Right now a duplicate counts as a function with same name and version. The code might still be different though. This flag is for deciding the strictness of the check. It could for example compare the checksums between the local version and the already uploaded version. Skip all duplicates, skip duplicates with matching checksum, skip no duplicates. --skip-duplicates all/matching-manifest/matching-checksum/none

Instead of busy-waiting on get, we should create a WaitForApproval endpoint in Avery that takes a RemoteAccessRequestId and simply waits until it is approved (by using a future, presumably). Lomax then sets the timeout to that call with https://docs.rs/tonic/latest/tonic/struct.Request.html#method.set_timeout. This way we do not busy wait with arbitrary sleeps and stuff will be more responsive.

Description

Currently, we use files to do stdout/stderr redirection in Avery. We should instead create a struct that implements WasiFile and can read stdout/stderr pipes and then write to file and stream to network.

Acceptance Criteria

• Bendini has a --follow flag that shows output (stdout+stderr) of the running function
• The --follow flag works over the network. I.e. the function is executed on another computer than bendini.

Ability to set a max size in config for function cache folder in avery

They are not really changes and should only be in the release description, not in the changelog.

Either just have a description or make it optional so it can be used where it makes sense

Today we have a field called order_direction in our ListRequest. It can be ascending or descending. This is not super nice for API users since they can decide what to sort on as well.

There are expectations on if things should be sorted ascending or descending depending on that field your sort on so it doesn't make sense to give the api user the choice.

For example name is expected to be ascending where version is expected to be descending.

We must decide a sensible default for asc and desc and instead provide the api user with an additional field to reverse the list results instead.

upgrading should not remove keyfiles or config
uninstall should

Avery with runtimes assumes it should output two things, windows and package. This means that any other os needs to alias itself to either package or windows to work. The function should take the target directly and not make any assumptions of what is available.

We've decided it's not really worth having two endpoints for uploading attachments. Kill the streaming grpc one.

Oath recommends hashing or encrypting it so it's not stored in plain text in the config.

https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/

Currently Avery is responsible for opening the browser window. This forces us to set the DISPLAY variable on unix platforms for something that is really a background service. The browser window should instead be opened by foreground clients like Bendini. Avery can send back an error code when acquiring credentials that need login with information on what browser page to open up. Bendini then opens the browser page and completes the login flow and after that tries to re-acquire the credentials.

• Need to make sure the PendingFileRenameOperations key exists when deleting
• If PendingFileRenameOperations key doesn't on cancel, just be happy

Instead of being a service, it should be added through the ServiceBuilder and the map_err function.

The user interface of firm-installer should not use a logging framework to print to the terminal. The buffered and asynchronous nature of it will make adding user features like progress bars or other interactive features harder than it should. It is also not what a logging framework is intended for. Writing down a log file (or using the event log) is of course ok.

In the case where a change is described in multiple lines such as the following example.

## Unreleased

### Added
- Added a seriously long line to the change log
  with a very descriptive description.

When we go into the release shell and prepare the changelogs and move it to the Firm changelog double lines are converted into separate items like in the example below.

## Firm [1.1.1]

### Added
- Added a seriously long line to the change log
- with a very descriptive description.

This is an unexpected behavior. We tracked the problem down to the keepachangelog python library only working on lines and not considering that a comment might be on several lines. https://github.com/Colin-b/keepachangelog/blob/3538c5b4beb433293352d084f4df7bcce4d02bf1/keepachangelog/_changelog.py

Suggested solutions:
1: We don't make newlines in comments.
2: Patch the keepchangelog parser, send them a pull request (https://github.com/Colin-b/keepachangelog).

All sockets should be pre-opened based on what is declared on the function like file system mapping.

The required github token does not work as a relative path, also it should accept either content or filepath. Check [ -f "$1" ] and take it as a filepath otherwise assume $1 is the content.

Currently it is just an int, could at least be a string.

Send execution context to WASI guests the same way we send in function context

Requirement is that it must not contain a company specific name.

Start by going to firm/protocols/rust/Cargo.toml and change the package name.
The same applies to our python version of the project at firm/protocols/python/setup.py.

Lots of other projects are using these types so make sure it builds with all of them. Preferably have fixes for other ready projects in other merge requests before merging the changes to main. It's just so it's ready for update with our internal projects once it gets merged.

You are on computer 1 and start avery for the first time (ignoring socket activation step) avery will create id_ecdsa.pem and id_ecdsa_pub.pem. Avery will then upload the public part to rolodex. Avery does not care if there is already an entry and overwrites the pub key in rolodex.

Now I remote in to computer 2 where I've already done those steps previously.
From this machine I use bendini to list functions on another users machine. I will fail to authenticate because the new pub key in rolodex does no longer match my local one since it got overwritten.

Suggested solution:
Support a list of public keys per user in rolodex.
Could do this change when we move auth out from avery.

The WASI APIs that we add need to be structured into different pieces. The pieces that can be implemented outside Avery should be implemented as a separate library and then the symbols are just exported in Avery or any other host. This would allow other hosts to use these APIs, for example an alternative Python executable. In that case, the wasi Python shims that we have should assume that something will provide the symbols needed to implement things like sockets, threads, etc.

The pieces that can only be implemented inside Avery should of course be implemented there but be part of a separate import/export namespace. This is for example support functions for node graphs (allocating streams, setting connections, queueing function execution etc.).