Não consigo salvar ClassMethod [ Language = python ]
Ao salvar o seguinte ClassMethod:
ClassMethod create() [ Language = python ] {
print("python")
}
o seguinte erro foi recebido:
Compilation started on 06/03/2026 02:15:21 with qualifiers 'cuk /multicompile=0'
ERROR #7802: Worker job/s '1078:17' unexpectedly shut down in group '#Default:(9119826733444):0'.
ERROR #7802: Worker job/s '1078:17' unexpectedly shut down in group '#Default:(9119826733444):0'.
Com as flags de compilação "cuk", o retorno é:
Compilation started on 06/03/2026 02:19:28 with qualifiers 'cuk'
Compiling class dc.RegionClinicalVectorGenerator
ERROR #7802: Worker job/s '1160:34' unexpectedly shut down in group '#Default:(6933525859080):0'.
ERROR #7812: Work queue unexpectedly removed, shutting down.
ERROR #5002: ObjectScript error: THROW WaitForComplete+215^%SYS.WorkQueueMgr *%Exception.StatusException ERROR #7802: Worker job/s '1160:34' unexpectedly shut down in group '#Default:(6933525859080):0'.
ERROR #7812: Work queue unexpectedly removed, shutting down.
Detected 3 errors during compilation in 1.006s.
ERROR #7802: Worker job/s '1160:34' unexpectedly shut down in group '#Default:(6933525859080):0'.
Meu dockerfile é:
ARG IMAGE=intersystemsdc/irishealth-community:latest
FROM $IMAGE
USER root
RUN mkdir -p /opt/irisapp && chown ${ISC_PACKAGE_MGRUSER}:${ISC_PACKAGE_IRISGROUP} /opt/irisapp
WORKDIR /opt/irisapp
ENV PIP_TARGET=${ISC_PACKAGE_INSTALLDIR}/mgr/python
COPY --chown=${ISC_PACKAGE_MGRUSER}:${ISC_PACKAGE_IRISGROUP} iris.script /
COPY --chown=${ISC_PACKAGE_MGRUSER}:${ISC_PACKAGE_IRISGROUP} ./src src
COPY --chown=${ISC_PACKAGE_MGRUSER}:${ISC_PACKAGE_IRISGROUP} ./data fhirdata
USER ${ISC_PACKAGE_MGRUSER}
RUN iris start IRIS \
&& iris session IRIS < /iris.script \
&& iris stop IRIS quietly
iris.script:
zn "%SYS"
do ##class(SYS.Container).QuiesceForBundling()
do ##class(Security.Users).UnExpireUserPasswords("*")
zn "HSLIB"
set namespace="FHIRSERVER"
Set appKey = "/fhir/r4"
Set strategyClass = "HS.FHIRServer.Storage.Json.InteractionsStrategy"
Set metadataConfigKey = "HL7v40"
set importdir="/opt/irisapp/src"
//Install a Foundation namespace and change to it
Do ##class(HS.Util.Installer.Foundation).Install(namespace)
zn namespace
// Install elements that are required for a FHIR-enabled namespace
Do ##class(HS.FHIRServer.Installer).InstallNamespace()
Do ##class(HS.FHIRServer.Installer).InstallInstance(appKey, strategyClass, metadataConfigKey,"",0)
// Configure FHIR Service instance to accept unauthenticated requests
set strategy = ##class(HS.FHIRServer.API.InteractionsStrategy).GetStrategyForEndpoint(appKey)
set config = strategy.GetServiceConfigData()
set config.DebugMode = 4
do strategy.SaveServiceConfigData(config)
zw ##class(HS.FHIRServer.Tools.DataLoader).SubmitResourceFiles("/opt/irisapp/fhirdata/", "FHIRServer", appKey)
// Import cls
do $System.OBJ.Import("/opt/irisapp/src","cuk")
Comments
You are probably not doing anything wrong in the class syntax itself. The retrieved material points instead to a problem where compiling or saving a class that contains an Embedded Python method can crash the worker process, producing errors like ERROR #7802, ERROR #7812, and work queue failures during compilation. A retrieved report shows essentially the same behavior with a method declared as [ Language = python ]. [1][2]
The retrieved material also indicates this is a reported issue on irishealth-community 2026.x. One source explicitly describes an “in-process Embedded Python crash on the 2026.x image (reported)” and calls it “a regression vs 2025.3”. [2]
Based on that material, the most likely explanation is that your intersystemsdc/irishealth-community:latest image is pulling a 2026.x build affected by this Embedded Python compilation problem, rather than there being an error in your ClassMethod create() [ Language = python ] code or in the example syntax you tested. [1][2]
A reported workaround in the retrieved discussion was to change from the 2026.x community image to intersystems/iris health-community:2025.1, which “worked normally” for another user with the same error pattern. [2]
The retrieved sources do not provide a documented fix for the compile-time crash itself. They only support the conclusion that this is a known/reported issue pattern affecting Embedded Python compilation in that environment. [1][2]
Sources: