@jasonpaulos let me know what you think about this general approach. If it looks good, I can work on the endpoint and more tests

@jasonpaulos this comment in the test you initially wrote got me thinking... Should we expect the transaction group to be modified in the response? Is there any precedent for this?

I feel like there is value in seeing the txn group as it was given and also seeing what was modified. Perhaps an additional field that indicates a changed signer per txn, but the actual transaction object remains unchanged?

Also I'm switching from the terminology "fix auth addr" to "fix signer" to avoid confusion between the auth addr for a given account in the ledger and the signer for the transaction, making it clear the ledger remains unchanged and its just txns that are getting modified.

Codecov Report

Attention: Patch coverage is 75.00000% with 18 lines in your changes missing coverage. Please review.

Project coverage is 55.90%. Comparing base (f633857) to head (7dc3716).
Report is 1 commits behind head on master.

@@            Coverage Diff             @@
##           master    #5942      +/-   ##
==========================================
+ Coverage   55.86%   55.90%   +0.04%     
==========================================
  Files         481      481              
  Lines       68357    68416      +59     
==========================================
+ Hits        38189    38251      +62     
+ Misses      27567    27565       -2     
+ Partials     2601     2600       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@jasonpaulos this comment in the test you initially wrote got me thinking... Should we expect the transaction group to be modified in the response? Is there any precedent for this?

I feel like there is value in seeing the txn group as it was given and also seeing what was modified. Perhaps an additional field that indicates a changed signer per txn, but the actual transaction object remains unchanged?

I agree that it would be preferable to not modify the transactions as given, and instead provide an additional response field with the overridden signer. The only problem is that the response structure may make it difficult to associate this additional information with inner transactions.

The only problem is that the response structure may make it difficult to associate this additional information with inner transactions.

Unless you are thinking of functionality that I am not, we're only modifying the signers on the outer transactions, so we only need to add additional information to the outers.

Unless you are thinking of functionality that I am not, we're only modifying the signers on the outer transactions, so we only need to add additional information to the outers.

Good point, this plan should have no problems then

@jasonpaulos I need to modify the test case to make sure the change I made in 89c20b5 works as expected with nested app calls, but other than that it's ready for review. <- Done