How to achieve invocation-level granularity for multiple resolver functions in a single Forge page?

Forge Forge Modules and Product Triggers
,
1

Hi everyone,

My name is Carlos Fernández, and I’m part of the Product team at Deiser

We’re developing several Forge apps using Custom UI, and I have a question about invocation monitoring and granularity in the developer console.

In my app, I define several functions using resolver.define() inside a single resolver handler (e.g., getText, getText2, etc.), and then I export that handler in my code:

const resolver = new Resolver();
resolver.define('getText', () => { ... });
resolver.define('getText2', () => { ... });
export const handler = resolver.getDefinitions();

In my manifest.yml, I associate this single resolver function with my global page:

modules:
  jira:globalPage:
    - key: my-page
      resource: main
      resolver:
        function: resolver
  function:
    - key: resolver
      handler: index.handler

The issue:
In the Atlassian Forge developer console (under “Invocations”), all the invocations for any of the defined resolver functions (getText, getText2, etc.) are grouped under the single handler name (resolver).
This means I cannot see which specific function was called, nor can I get invocation times or metrics per resolver function — everything is aggregated at the handler level.

My questions:

  1. Is there any way to achieve more fine-grained monitoring/metrics for each resolver.define function, so I can see which function was actually invoked from the frontend, and how often?
  2. Is the only option to have one resolver handler per function (and thus per page/module), or is there any workaround to get per-function granularity in monitoring?
  3. How do you handle this in your apps if you have many logical backend functions behind a single resolver handler?

Any advice, best practices, or insight would be appreciated!

Thank you!

Carlos Fernández

2

The console meters per manifest function, not per resolver.define. A module binds exactly one resolver function, and every invoke() from your Custom UI hits that one function, so the define() dispatch happens in-process after the platform has already counted a single invocation of resolver. That aggregation is by design, not something you can split from config. The invocation-time metrics only group by version and function, so per-operation timing isn’t something the console exposes today.

We ran into the same wall in CogniRunner (~20 defines behind one handler). We stopped relying on the console for per-op visibility and wrap each define to log the operation name and elapsed:

const track = (name, fn) => async (req) => {
  const t = Date.now();
  try { return await fn(req); }
  finally { console.log(`op=${name} ms=${Date.now() - t}`); }
};
resolver.define("getText", track("getText", getText));

We persist that line to storage and read it back in an in-app Logs panel so it outlives the forge logs window. The whole setup is open source under Apache-2.0 if it’s useful (I’m from LeanZero, we build it).

3

Hi @Mihai_leanzero ,

Thank you for this code snippet.

The code is AGPL, that means we are not allowed to deploy it into Forge, as Atlassian forbids AGPL in Forge (see https://developer.atlassian.com/platform/forge/developer-terms/ 1.).

4

Thanks, and yeah, that’s correct. I picked AGPL for CogniRunner on purpose, to keep it open but stop it getting quietly stripped into a closed product. The flip side is the one you hit: copyleft doing exactly what I asked it to do is also the thing you can’t drop into your own Forge app, which rather undercuts the point of sharing the snippet.

So reuse wins over the copyleft guard. It’s Apache-2.0 now, headers and all, and I checked the dependency tree is clean of copyleft while I was in there. Anything from the apache-2.0 tag onward is fair game for a Forge app, the older commits stay AGPL. Apache rather than MIT for the NOTICE attribution and the patent grant, since keeping attribution was the part I actually cared about.