Push to PRD #224
Merged
Push to PRD #224
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Collaborator
bitbeckers
commented
Jan 24, 2025
bitbeckers
commented
- Safe signature support for User entities
- File upload endpoint
- Test suites
- Attestation fetching and resolver updates
The user controller had a lot of repetetive code. This patch dry's this code up quite a bit and makes the high-level intent more apparent.
Without this patch the user controller only allows updating the user data directly via EOA. Calling it with a multisig like the Safe would fail as the smart wallet isn't able to create a signature. In this instance the API needs to track signature requests, so that the user data can be written once the signature threshold is met. The need to track these signature requests arises from the fact that you cannot delete signatures from the Safe once they were "used". They will stick around forever and it is up to us to track which signature corresponds to which change, if it is discarded or implemented, etc. The patch introduces a new folder: src/lib/users. The reason is that the project is currently structured by implementation details, so I wanted to keep the user controller in with the rest of the controllers but have a place to store this business logic.
Without this patch we can only write signature requests, but not fetch them. This patch implements the required resolvers and also exposes any signature requests that are registered for a particular user.
Without this patch the user has no way of canceling signature requests. This patch introduces a status field. It has 3 possible values: PENDING, CANCELED and EXECUTED. The controller allows canceling the signature request only when it's in status PENDING and the caller authenticates as one of the owners of the Safe.
Without this patch we're missing a way for the API to execute the signature requests and commit the data to record if the signature threshold is met. This patch adds the request POST /signature-requests/process which reads all **pending** signature requests from the data DB, checks if the confirmations meet the signature threshold and if so writes the attached username and avatar changes to the users table. To stay within the rate limit of 5 requests per second required by the Safe API I implemented a rate limited queue and worker that process them concurrently. The request doesn't require authentication, so it could be invoked by a CRON job, as well as the user when they log in or specifically request an update.
This directive didn't have any effect.
In case somebody is wondering why we have duplicate type definitions in our code base.
Without this patch adding a new signature request to the database doesn't invalidate the cache right away. This needs to be triggered manually.
As the class is the only export in that module, it's better to have it as a default export.
The file wasn't prettier formatted yet and making a change to it would result in a huge diff with 99% styling changes.
Without this patch we rely on users making a POST request to /v1/signature-requests/process to kick off signature request processing. Since it's not going to be high load, we want to have a regular cron job that relieves users of that duty and will run signature request validations on autopilot. This way users just have to wait a bit to find their signature requests validated once the Safe message has reached the required threshold. Also made a small change to the log statement in the processor to make it more clear that it's running signature requests, now that a console log will show up every 30 seconds.
Safe integration for profile updates
Run cron job to start Safe signature requests queue processing
Fixes the test file and controller to have passing tests and better error handling for the metadata upload functionality of the MetadataController
Restores the metadata validation endpoint testing. Additionally the full metadata controller is using try catches and we updated the response types. The response types have been made more simple and flexible, for one to support the cases of validation where the processing can be successful but the data is invalid. Lastly, responses where data is set as null were cleaned so simply not return data.
Update all controllers to use the updated types structure. Rebuild the updated API routes and Swagger.
Fixes the allowlist upload unit test flows. The current test suite was breaking on missing imports and the tested flow and types were updated to the latest implementation
wraps business logic in try-catches and updates response types where needed
Adds vitest coverage reporting and CI action
Fixes the test file and controller to have passing tests and better error handling for the metadata upload functionality of the MetadataController
Restores the metadata validation endpoint testing. Additionally the full metadata controller is using try catches and we updated the response types. The response types have been made more simple and flexible, for one to support the cases of validation where the processing can be successful but the data is invalid. Lastly, responses where data is set as null were cleaned so simply not return data.
Update all controllers to use the updated types structure. Rebuild the updated API routes and Swagger.
Adds vitest coverage reporting and CI action
…rcerts-api into feat/init_testing_ci
updates gha test script to use env var
Set up test suites and testing CI
Adds an upload endpoint to our API. This has been implemented using multer as a middleware for file validations and restrictions on file size. Basic happy/unhappy flow tests pass.
Increases coverage threshold based on updated test suite Updates the types used in lib/users to match updated API types Generated updated Swagger
Add validations on file type and size
To gradually clean up the repo, we agreed on restructuring helpers from utils to more cleanly scoped libs. Additionally, added some tests
- Introduced a new script for batch minting blueprints from a CSV file - Added a new CSV file to define example blueprint data. - Updated `package.json` to include new dependencies: `@inquirer/prompts` and `csv-parse`. - Modified `BlueprintController` to make the `cardImage` field optional in validation.
…-script feat: blueprint batch minting form
…ns longer than 100 characters
- Added `hypercerts` field to the Blueprint type in the GraphQL schema. - Updated BlueprintResolver to include a new FieldResolver for fetching hypercerts based on `hypercert_ids`. - Modified the Blueprint type definition to include the new `hypercerts` field - Modified the blueprints type definition to include internal `hypercert_ids` field for data handling.
Updates the UploadController to use custom errors. The custom errors are defined in a uploads lib directory and handles all cases found in the controller.
Updates the UploadController typedoc example to document different upload tools and the expected responses
Adds typeguards and updates the parsing of failed and successful file uploads for readability
Updates the test cases to test on the expanded upload result types. Additionally typedoc documentation was updated to document the error and the controller more accurately.
File upload endpoint
At 10 osme files around 9.7 failed. This is the ducttape solution until we've resolved the issues
…percerts-relation Feat/expose blueprints hypercerts relation
Updates Attestation resolver, input and args to support fetching attestations based on schema data. This enables queries based on schema uids
updates generated graphql schema
Updates the where clause and field name to use eas_schema which is more intuitive
…_with_schemas Attestation resolver with schemas
Updates test suite to work with file limits. Update testing to cover more edges cases. Testfiles were renamed to match the file they were testing
Set upload limit to 11MB
- Introduced separate arrays for testnet and production chains for better organization, and because .testnet property is not always defined in viem. - Updated chain selection logic to determine if the selected chain is a testnet based on the new structure.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.