Forum Discussion
Java MIP SDK 1.17.154: commitAsync() TemplateNotFoundError (C# OK; Java fails Win & Ubuntu)
TL;DR
- Java SDK 1.17.154: calling setLabel() then commitAsync() fails with TemplateNotFoundError (TemplateId=2ea3c830-...).
- Same label/code works on Java 1.16.x and C# 1.17.154.
- Policy cache cleared, templates/labels verified, token/tenant checked—issue persists.
Environment
- SDK (Java): 1.16.x (OK), 1.17.154 (FAIL)
- SDK (C#): 1.17.154 (OK)
- OS (Java): Windows 10/11 (win32 build), Ubuntu 20.04 / 22.04 / 24.04
- Java: OpenJDK 17.0.16 (x64)
- Service/Tenant: Microsoft Purview Information Protection
- Auth: (e.g., user delegated token / app-only token)
Code Snippet (Java)
// Label apply options
LabelingOptions labelingOptions = new LabelingOptions();
labelingOptions.setAssignmentMethod(AssignmentMethod.PRIVILEGED);
labelingOptions.setDowngradeJustified(true);
labelingOptions.setJustificationMessage("Label Apply");
// Get label
Label label = fileEngine.getLabelById(labelId);
// Apply label (no explicit template handling)
fileHandler.setLabel(label, labelingOptions, new ProtectionSettings());
// Commit
File workFile = new File(domainFolder, UidUtil.makeUid());
CompletableFuture<Boolean> commitFuture = fileHandler.commitAsync(workFile.getAbsolutePath());
commitFuture.get(); // <-- Throws TemplateNotFoundError on 1.17.154
Stack trace excerpt:
Caused by: com.microsoft.informationprotection.internal.gen.Error: TemplateNotFoundError:
Could not find template with id: 2ea3c830-5a0e-4eea-b48b-c72186d453c0, BadInputError.Code=General,
CorrelationId=42ffaad4-3a0f-4986-ba9d-b5a79c5fd076 (ProtectionEngine),
CorrelationId=16819f70-e419-473f-9895-c756f3dd5e4b (FileHandler)
at com.microsoft.informationprotection.internal.gen.SdkWrapperJNI.SwigDirector_FileHandler_Observer_OnCommitFailure(SdkWrapperJNI.java:2688)
Expected Behavior
setLabel() should apply the label (and its protection) and commit successfully, as it does in Java 1.16 and C# 1.17.154.
Actual Behavior
commitAsync() fails with TemplateNotFoundError for the GUID referenced by the label’s ApplyProtectionAction.
What I’ve Tried
- Policy/cache refresh: Deleted %LOCALAPPDATA%\Microsoft\MSIP\ / ~/.mip/, reloaded engine.
- Template/label verification: Confirmed existence and publish scope in Purview portal & via PowerShell/Graph.
- Label actions check: policyEngine.getLabelActions(labelId) shows an ApplyProtectionAction with that GUID.
- Token/tenant sanity check: Correct scopes and same tenant.
- Rollback test: Java 1.16 works; C# 1.17.154 works.
Questions
- Any breaking change in Java 1.17 regarding how protection templates are resolved during setLabel()?
- Is this a known issue specific to Java SDK 1.17.154 (win32 & Ubuntu 20/22/24 builds)?
- Should we now explicitly use ProtectionDescriptor / SetProtection() in Java?
- Can someone review the service logs using the CorrelationIds above?
Happy to provide additional logs, PowerShell/Graph queries, or action dumps if needed. Thanks!
2 Replies
- HyderAliCopper Contributor
mip sdk recent versions introduced the offline publishing and it is enabled by default. For your issue can you try with the following
map<mip::FlightingFeature, bool> featureSettingsOverride;
featureSettingsOverride[mipns::FileSDKOfflinePublishing] = false;- mjseongCopper Contributor
Hi HyderAli,
Thank you for your suggestion.
I appreciate your comment from July 31, 2025, where you mentioned:
“mip sdk recent versions introduced the offline publishing and it is enabled by default. For your issue can you try with the following"
map<mip::FlightingFeature, bool> featureSettingsOverride; featureSettingsOverride[mipns::FileSDKOfflinePublishing] = false;
As you correctly pointed out, this approach applies to the C++ SDK (and similar functionality exists in .NET), thanks to the availability of FeatureSettingsOverride.
Unfortunately, in the Java SDK, the current wrapper does not provide any equivalent API or configuration option to disable offline publishing.
Therefore, in our Java-based wrapper implementation, it is not possible to disable offline publishing using the method you suggested.
If you’re open to exploring workarounds, here are two possible directions we could consider:
- Roll back to Java SDK version 1.16, where offline publishing may behave differently or not be enabled by default.
- Implement a native C++ or .NET module that handles protection workflows with offline publishing disabled, and invoke it from Java via JNI or a REST gateway. The module would handle protection and produce the final output, which Java would then consume.
Thanks again for your input. I’d be glad to discuss these options further if you wish.
Best regards,
mjseong