I don't think this helper function is necessary -- logic can be inlined. Feel free to argue otherwise.

The duplication between dynamodb and dynamodb-test is a problem. We should investigate this in a follow-up: from the localstack docs, it looks like separate databases with separate tables are created for each credential that connects https://docs.localstack.cloud/localstack/configuration/#dynamodb. So ideally terraform would just create the tables twice somehow with different credentials, one for test and one for dev.

wallet_login just doesn't seem necessary. What's wrong with the existing siwe API you're calling in this helper?

First, break this into subroutines for readability and reuse across DB fetchers. Like you should have functions parseTimestampAttribute, parseAuthType, etc and call parseTimestampAttribute(item.remove("created")).

I think this would be better as two functions create_simple_primary_key(partition_key) and create_composite_primary_key(partition_key, sort_key). Terminology from https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.CoreComponents.html#HowItWorks.CoreComponents.PrimaryKey.

Yeah looks good

Just a couple ways to make things more concise and/or readable. Feel free to ignore if you don't like it.

Create a real error type

Resigning as reviewer b/c I don't condone 80 char line limits. :-P

Made issue https://linear.app/comm/issue/ENG-1089/dont-copy-dockerfile-into-service-images

Ah, interesting. So I intended for the scripts to not get copied twice by putting docker/ in the .dockerignore (see services/backup/.dockerignore). However, that is not actually working and preventing the files from getting copied because apparently the .dockerignore must be in the root of the context -- unlike gitignores, docker doesn't check every subdirectory for a .dockerignore.

You should add a required_providers declaration somewhere like providers.tf. See https://registry.terraform.io/providers/hashicorp/aws/latest/docs.

Nice!

OK

Yeah, if you're deploying to prod with docker-compose, I'd just make a separate docker-compose.prod.yml and you can do docker-compose -f docker-compose.prod.yml.

I think you should just make a proper CLI for starting the service with one subcommand "server" or something to start the server and "keygen" to run your script. Instead of having a separate binary.

As noted, COMM_SERVICES_DEV_MODE should not be a compile-time flag, please fix

One thing to fix before landing

Rebased

1. This should expect the context to be the root directory, like the other services. See how in docker-compose.yml the other services specify the context is "../". Pretty sure the whole point is just to get access to the common proto definitions for now, but it's good for the service builds to be as similar as possible even though this is Rust and the others are C++.

Maybe a crude approach, but we could add something like yarn nix-dev to package.json as an alias for nix develop --extra-experimental-features nix-command --extra-experimental-features flakes?

This doesn't seem like a good approach, see my comments on D3495. How were these tables and buckets created in the production DB? Were these commands run manually? The same script or migration system should be used in both local and production environments. This approach doesn't permit that because necessarily one database environment has to be set up to create the schema backup which is used to bootstrap the dev environment.

First, there should probably be separate diffs for S3 and DynamoDB as these are very different use cases in my opinion.

I think it's much better to abandon this and use a local dynamodb service in the docker-compose like https://hub.docker.com/r/amazon/dynamodb-local or https://github.com/localstack/localstack. It's a much simpler and more maintainable solution.

Rebased

• Rename build dir from _build to build

Add a root = true at the top. From docs "root: special property that should be specified at the top of the file outside of any sections. Set to true to stop .editorconfig files search on current file."

In D3399#92777, @karol-bisztyga wrote:

What is the reason behind having grpc flags passed to the cmake in the bash script instead of having them directly in the cmake file?

In D3395#91819, @ashoat wrote:

Wonder if we should check in an .editorconfig into the repo

Oops, just updated my .editorconfig