Composer integration #457

PatrickDinh · 2025-11-12T03:47:27Z

Proposed Changes

…ation

neilcampbell · 2025-11-14T15:15:58Z

packages/transact/src/transactions/transaction.ts

              return result
            })()
          : undefined,
+        rejectVersion: bigIntCodec.decodeOptional(transactionDto.aprv),


Suggested change

rejectVersion: bigIntCodec.decodeOptional(transactionDto.aprv),

rejectVersion: numberCodec.decodeOptional(transactionDto.aprv),

neilcampbell · 2025-11-14T15:16:08Z

packages/transact/src/transactions/app-call.ts

+  /**
+   * The lowest application version for which this transaction should immediately fail. 0 indicates that no version check should be performed.
+   */
+  rejectVersion?: bigint


Suggested change

rejectVersion?: bigint

rejectVersion?: number

neilcampbell · 2025-11-14T15:16:21Z

packages/transact/src/encoding/transaction-dto.ts

  apep?: number

+  /**  Reject version */
+  aprv?: bigint | number


Suggested change

aprv?: bigint | number

aprv?: number

neilcampbell · 2025-11-14T15:19:20Z

src/transaction/legacy-bridge.ts

+      // Populate the composer with method calls
      if ('transactions' in transaction) {
-        transaction.methodCalls.forEach((m, i) => sendParams.atc!['methodCalls'].set(i + baseIndex, m))
+        transaction.methodCalls.forEach((m, i) => sendParams.transactionComposer!['methodCalls'].set(i + baseIndex, m))


This feels hacky. Maybe it's ok because it's in the legacy code.

yeh it's pretty hacky. The problem comes from here

const transaction = await txn(transactionCreator)(params)

this causes the trasaction to be a txnWithSigner => when it's added to the composer, the methodCalls map isn't updated.

src/transaction/perform-transaction-composer-simulate.ts

neilcampbell · 2025-11-16T18:25:00Z

src/types/composer.ts

-   * Builds an ABI method call transaction and any other associated transactions represented in the ABI args.
-   * @param includeSigner Whether to include the actual signer for the transactions.
-   *  If you are just building transactions without signers yet then set this to `false`.
+   * Compose all of the transactions without signers and return the transaction objects directly along with any ABI method calls.


This does return signers as well

The jsdocs confused me as first too because this method returns the signer Map. I think it means that the transactions returned doesn't have signers attached. Should I change the docs?

Yes I think the docs should be updated to be clearer.

neilcampbell · 2025-11-16T18:34:02Z

src/types/composer.ts


+    const builtTransactions = await this.buildTransactions()
+    const transactions =


Doesn't buildTransactions take care of grouping?

No, buildTransactions doesn't do grouping. Grouping is applied in build, after resource population and fee coverage.

You mentioned this makes me think that the names buildTransactions and build are confusing. I kept them because:

buildTransactions existed in the composer. It does similar functionality.

build existed in the composer, but private. In main, resource population + fee coverage happen in send, for this version, I lifted them to build
I'm happy to find better names for them but that means breaking changes.

neilcampbell · 2025-11-16T18:37:02Z

src/types/composer.ts

      const error = new Error(errorMessage)

      if (Config.debug) {
-        await Config.events.emitAsync(EventType.TxnGroupSimulated, { simulateResponse })
+        await Config.events.emitAsync(EventType.TxnGroupSimulated, { simulateTransaction: simulateResponse })


The utils-ts-debug repo provides a handler for this event, so we need to think about migration and breaking changes here.

I'll add a note to the migration doc

src/types/composer.ts

neilcampbell · 2025-11-16T18:41:44Z

src/types/composer.ts

+  return (
+    ctxn.type === 'appCall' ||
+    ctxn.type === 'methodCall' ||
+    (ctxn.type === 'txnWithSigner' && ctxn.data.txn.type === TransactionType.AppCall)


What about asyncTxn?

I'll remove this function, it isn't needed anymore. In build (where it was used) I have access to the built transaction, I can check for the transaction type directly.

PatrickDinh · 2025-11-19T03:26:18Z

src/types/composer.ts

@@ -547,19 +234,19 @@ export interface BuiltTransactions {
  signers: Map<number, algosdk.TransactionSigner>
 }

+class BuildComposerTransactionsError extends Error {


@neilcampbell I created this error type for errors during build transactions. I think this is helpful because before this, in debug mode, if something goes wrong during resource population, we will need to run simulate again in the error handler. Using this error type, we can surface to simulation result to the error handler => eliminate the need to simulate again.

I like the idea, however this also become part of the public interface of the composer and an exception that a user may receive. I'd be inclined to keep as before and run another simulate. It only occurs in debug mode, which should only be enabled in testing scenarios (non prod).

PatrickDinh · 2025-11-19T03:27:30Z

src/types/app-client.spec.ts

    expect(clonedAppClient.appId).toBe(appClient.appId)
    expect(clonedAppClient.appName).toBe(appClient.appName)
-    expect((await clonedAppClient.createTransaction.bare.call()).sender).toBe(testAccount2.addr.toString())
+    expect((await clonedAppClient.createTransaction.call({ method: 'default_value', args: ['test value'] })).transactions[0].sender).toBe(


I had to update this test to use valid transaction params because the transaction creator now calls composer.build(), resulted in a simulate call.

Interesting. This is also a behavioural change. I'm actually wondering if it's better to not run resource population when using the TransactionCreator? Another thing that jumped to mind, is how would a user disable this behaviour?

Another approach is we could default to not populating resource in the transaction creator, however perform population if the user explicitly sets populateAppCallResource: true, when creating the AlgorandClient/AppClient?

src/types/composer.ts

neilcampbell · 2025-11-21T07:03:39Z

src/transaction/perform-transaction-composer-simulate.ts

+        stackChange: true,
+        stateChange: true,
+      },
+      throwOnFailure: false,


Would this technically be a breaking change? I'm assuming we'd previously throw on failure?

neilcampbell · 2025-11-21T07:09:02Z

src/transaction/transaction.spec.ts

+          sender: testAccount,
+          receiver: externalClient.appAddress,
+          amount: (1).algo(),
+          signer: testAccount,


This shouldn't be needed, as fixture.newScope() should have added the signer account.
Does this indicate some kind of behavioural change?

neilcampbell · 2025-11-21T07:12:30Z

src/transaction/transaction.ts

+    // if skipWaiting to true, do not wait
+    // if skipWaiting to set, wait for maxRoundsToWaitForConfirmation or 5 rounds


Suggested change

// if skipWaiting to true, do not wait

// if skipWaiting to set, wait for maxRoundsToWaitForConfirmation or 5 rounds

// if skipWaiting is true, do not wait

// if skipWaiting is false, wait for maxRoundsToWaitForConfirmation or 5 rounds

neilcampbell · 2025-11-21T07:23:44Z

src/transaction/transaction.ts

-    t.txn.group = undefined
-    newAtc.addTransaction(t)
-  })
+  await newComposer.build()


This will technically group the transactions which the previous code does not (Is that correct?).
If we wanted to keep the same behaviour, we could build, then return a clone?

neilcampbell · 2025-11-21T07:27:07Z

src/transaction/transaction.ts

- * Returns the array of transactions currently present in the given `AtomicTransactionComposer`
- * @param atc The atomic transaction composer
+ * Returns the array of transactions currently present in the given `TransactionComposer`
+ * @param atc The transaction composer


Suggested change

* @param atc The transaction composer

* @param composer The transaction composer

neilcampbell · 2025-11-24T01:40:09Z

src/types/composer.ts

-   * Builds an ABI method call transaction and any other associated transactions represented in the ABI args.
-   * @param includeSigner Whether to include the actual signer for the transactions.
-   *  If you are just building transactions without signers yet then set this to `false`.
+   * Compose all of the transactions without signers and return the transaction objects directly along with any ABI method calls.


Yes I think the docs should be updated to be clearer.

neilcampbell · 2025-11-24T01:45:11Z

src/types/composer.ts

   * @example
   * ```typescript
   * const { atc, transactions, methodCalls } = await composer.rebuild()
   * ```
   */
  async rebuild() {
-    this.atc = new algosdk.AtomicTransactionComposer()
+    this.transactionsWithSigners = undefined


Do we need to also do this.signedTransactions?

If so, i think it make sense to extract this logic into a private reset() method, which can be called by send() (in the scenario where resource population/fee coverage settings are different) as well.

neilcampbell · 2025-11-24T01:52:27Z

src/types/composer.ts

+    })
+
+    maxFees.forEach((maxFee, index) => {
+      this.txns[index].data.maxFee = new AlgoAmount({ microAlgos: maxFee.microAlgos })


Suggested change

this.txns[index].data.maxFee = new AlgoAmount({ microAlgos: maxFee.microAlgos })

this.txns[index].data.maxFee = maxFee

neilcampbell · 2025-11-24T01:55:37Z

src/types/composer.ts

@@ -547,19 +234,19 @@ export interface BuiltTransactions {
  signers: Map<number, algosdk.TransactionSigner>
 }

+class BuildComposerTransactionsError extends Error {


I like the idea, however this also become part of the public interface of the composer and an exception that a user may receive. I'd be inclined to keep as before and run another simulate. It only occurs in debug mode, which should only be enabled in testing scenarios (non prod).

neilcampbell · 2025-11-24T02:00:19Z

src/types/composer.ts

+  // Note: This doesn't need to be a private field of this class
+  // It has been done this way so that another process can manipulate this values, i.e. `legacySendTransactionBridge`
+  // Once the legacy bridges are removed, this can be calculated on the fly
+  private methodCalls: Map<number, algosdk.ABIMethod> = new Map()


Having to keep this in sync isn't great. I'm wondering if we could instead calculate on the fly (as you mentioned above), however add a private method which the legacy bridge can call?

PatrickDinh added 30 commits October 31, 2025 14:53

review + notes

43381a2

wip - integration

d9e89a4

Merge branch 'feat/transact-integration' into composer-integration

075667f

wip - add transactions into the composer

6278023

wip - build transactions

cc3447e

wip - build app call

71d11d4

wip - done app call

447bba9

wip - method call

0fcd051

wip - build method calls done

5112899

wip - resource population

3943837

wip - done simulate

7a59dfb

wip - composer send

7d55cb8

wip - refactor to keep the public interface

653c14d

comment out test - can build and check types now

498d8ec

wip - fixing tests

d69dc7d

wip - fix tests

52292a2

wip - fix signer for nested txn

9c836c0

update error message

d105e4c

Merge branch 'feat/transact-integration' into composer-integration

f64509d

Merge branch 'feat/transact-integration' into composer-integration

9026768

Merge branch 'feat/transact-integration' into composer-integration

d4ee22f

fix types

d2bcf37

reject version

282cd24

access list for method call

5459220

wip - remove atc

e7bb6e2

wip - convert calls to atc to transaction composer

d93034f

wip - remove atc - check types good

8f9b54b

Merge remote-tracking branch 'origin/decoupling' into composer-integr…

b9d5634

…ation

oops missed one

e75fd10

fix import paths

ecbde70

PatrickDinh added 3 commits November 13, 2025 11:27

apply the extra page fix

f52215e

delete files from sdk

f8a4283

review notes

ed682ad

neilcampbell reviewed Nov 16, 2025

View reviewed changes

PatrickDinh added 4 commits November 17, 2025 10:18

wip - PR feedback

d855cc7

pr review - refactor composer to hold maxFee for raw txns

163815f

wip - pr feedback

f16ced1

wip - PR feedback

09000c2

PatrickDinh force-pushed the composer-integration branch from db98a4b to 09000c2 Compare November 17, 2025 04:30

PatrickDinh added 10 commits November 17, 2025 14:53

PR feedback - add fee coverage tests

af4c7c0

use shallow clone

e97cf06

wip - refactor build methods + simulate

fc3c33d

test snapshot

da2c47f

TODOs

f6c0c62

wip - review

0bdabbe

wip - TODO

fc1f2e0

more TODO

d44e14a

review

a76eebe

fix

fc1ac3a

PatrickDinh commented Nov 19, 2025

View reviewed changes

PatrickDinh commented Nov 20, 2025

View reviewed changes

src/types/composer.ts Show resolved Hide resolved

PatrickDinh added 3 commits November 20, 2025 10:07

refactor + test

add078d

fix performTransactionComposerSimulate

1658920

move the build common data logic into txn builders

81eb6be

neilcampbell reviewed Nov 24, 2025

View reviewed changes

PatrickDinh added 5 commits November 24, 2025 21:36

bring back buildTransactions with better docs

4194514

wip - remove BuildComposerTransactionsError

dcf1786

adjust error handling logic

ebf33c3

drop deprecated methods and types from v7

9674246

wip - fix types

e721ae6

	rejectVersion: bigIntCodec.decodeOptional(transactionDto.aprv),
	rejectVersion: numberCodec.decodeOptional(transactionDto.aprv),


		const builtTransactions = await this.buildTransactions()
		const transactions =

		// if skipWaiting to true, do not wait
		// if skipWaiting to set, wait for maxRoundsToWaitForConfirmation or 5 rounds

	* @param atc The transaction composer
	* @param composer The transaction composer

	this.txns[index].data.maxFee = new AlgoAmount({ microAlgos: maxFee.microAlgos })
	this.txns[index].data.maxFee = maxFee

Composer integration #457

Are you sure you want to change the base?

Composer integration #457

Conversation

PatrickDinh commented Nov 12, 2025

Proposed Changes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants