This documentation is intended for Confluence developers who want to ensure that their existing plugins and apps are compatible with Confluence 11.1.

Watch this page to find out when a new milestone is available and what’s changed. We will publish formal release notes once we release a beta.

Latest milestones

Issues with this milestone?

Hit the Feedback button on the Confluence EAP header or raise an issue to tell us about it.

On this page:

Planned changes

In this section we'll provide an overview of the changes we intend to make, so you can start thinking how it might impact your app. We'll indicate when a change has been implemented, and in which milestone. 

App-specific diagnostic logging API

Status: EXPERIMENTAL

Confluence Data Center 11.1 introduces an experimental API that lets apps temporarily enable detailed logging for their own packages and collect the output for display in an app’s diagnostic screen. This supports troubleshooting, such as a test login or synchronization run, without access to Log4j Core. Apps can import the AppDiagnosticsService OSGi service from com.atlassian.confluence.logging.diagnostics to:

• Capture logs using startLogCapture, which returns an AppLogCapture backed by a bounded, time‑limited buffer. Capture alone does not enable DEBUG.
• Temporarily raise logging verbosity to INFO or DEBUG using raiseLogLevel, which returns a TemporaryLogLevelChange. Close the handle when finished; the previous level is restored on close or expiry unless an administrator changed it in the meantime.

Both operations are restricted to packages owned by the calling app and apply only to the current cluster node. Captures span threads and requests; they are not isolated to a single user or operation.

Preparing your app: adoption is optional. Use this API for diagnostic workflows that previously required direct logging configuration or custom appenders. Apps supporting earlier Confluence versions should import the API optionally and handle its absence.

Performance and security: keep package prefixes narrow and durations short. DEBUG output may also reach ordinary log files; capture limits do not restrict that output. Protect diagnostic results before displaying or sharing them.

Asynchronous Macro Framework : Enhancements

Status: EXPERIMENTAL

11.1 extends 11.0's asynchronous macro execution with new opt-in APIs, a broader execution key, and stricter thread isolation.

What's new:

• Macro.isDeduplicationSafe() - new method that lets macros specify de duplication support. False by default.

• ConversionContext.disableAsyncMacroExecution()/isAsyncMacroExecutionDisabled()- forces a particular conversion fully synchronous, overriding the dark feature, admin settings, and the macro's own declaration. It is inherited by nested same-thread conversions (e.g. Include Page); but does not cross a thread hand-off you create yourself.

• Selected bundled macros now declare concurrency-safety and/or deduplication-safety individually. Not every bundled macro opted into both, or either.

• Execution key now includes content ID, space key, output type, and locale, not just name/params/body hash/user. Identical markup in different contexts can no longer wrongly share a cache/dedup entry.

• Macro.getAsyncKeySupplement(ConversionContext) - new method to fold any remaining external state into that key.

• Execution Key is now a snapshot, not a live reference - captured immutably at computation time, so mutating the parameter map afterward can't change it.

• Content include stack is now per-worker-thread, not shared - one include's recursion guard can't be corrupted by a concurrent sibling.

Preparing your app: Both opt-ins are optional. Skip isDeduplicationSafe() if output embeds anything non-deterministic (random IDs, one-time URLs, another page's live content).

Skip isConcurrentExecutionSafe() if your macro is a singleton storing per-invocation state in instance fields. One instance is shared by every concurrent render, so writes leak across unrelated invocations.

If your code hands rendering off to a private executor rather than the asynchronous macro engine, it is responsible for propagating any per-conversion state itself - the disable-async flag and anything else read from ConversionContext, since none of it crosses that hand-off automatically.

Compatibility: Macro identity queries now resolve against the ConversionContext that owns the current execution, rather than the macro that most recently executed on the thread. A nested conversion started during a macro's execution (for example, rendering another page's content), does not inherit the outer macro's identity unless it is explicitly re-established for that context.

Implemented changes

In this section we'll provide details of changes we have implemented, organised by the milestone they are first available in. This will help you decide which milestone to use when testing.

EAP 01 – 4 November 2026

Milestone 11.1.0-m48

Contains:

• App-specific diagnostic logging API

• Asynchronous Macro Framework : Enhancements

• Minor bug fixes