When building with -T6, multiple JS modules run yarn install concurrently.
The --mutex network flag serializes yarn processes, but if node_modules from
a previous build (or a different branch/version) is left on disk, yarn may
skip reinstalling packages — including devDependencies — treating the stale
state as up-to-date. This causes tools like tsc to be missing at build time.
Configure maven-clean-plugin to delete node_modules during mvn clean for
all JS modules (ui-ngx, msa/js-executor, msa/web-ui). Yarn restores from
its global cache (~/.cache/yarn), so the overhead is relinking only.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
When Execute RPC is sent to FW Update resource (/5/0/2), the test client's
startUpdating() scheduled the client stop with 0 delay. This caused a race
where the client stopped before the CoAP Execute response (2.04 Changed)
was delivered to the server, resulting in RequestCanceledException and
INTERNAL_SERVER_ERROR instead of CHANGED.
Adding a 1-second delay before leshanClient.stop() ensures the CoAP
response is transmitted and received before the client disconnects, fixing
the flaky testExecuteUpdateFWById_Result_CHANGED test.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Using the same connection for both SCAN cursor iteration and GET value
fetches causes Jedis 5.x response-ordering corruption: the SCAN response
parser receives a GET response (byte[]) where it expects a List, and vice
versa, resulting in ClassCastException on startup.
Fix: open two connections per getAll() call — one dedicated to the scan
cursor and one for value fetches — eliminating any interleaving.
Affected: TbRedisLwM2MClientStore, TbRedisLwM2MModelConfigStore,
TbLwM2mRedisRegistrationStore.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Tests that read shared static state (e.g. testAllowedUrls with 8.8.8.8)
could run concurrently with tests that mutate it (e.g. testAdditionalBlockedSingleIp),
causing intermittent failures. Class-level @ResourceLock serializes all tests.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Use ID token claims as the source of truth for Apple OAuth2 attributes
- Added Apple mapper type to OAuth2 client data validation
- Consolidated duplicated validation logic for BASIC, GITHUB, and APPLE mapper types
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The lastCommit field was shared across all repository keys, causing
MissingObjectException when multiple repositories were registered.
When onUpdate fired for repo A it overwrote lastCommit, and subsequent
listFiles/getFileContent calls for repo B used repo A's commit whose
tree objects don't exist in repo B's object database.
Changed to a per-key Map<String, RevCommit> so each repository's
resolved commit is stored and retrieved independently.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Move TestDbCallbackExecutor from rule-engine test sources to
common/util main sources as DirectListeningExecutor, making it
available to all modules. Convert to an enum singleton since the
executor is stateless. Widen JpaAbstractDaoListeningExecutorService
service field type from JpaExecutorService to ListeningExecutor to
allow injecting DirectListeningExecutor in tests. Fix
AbstractChunkedAggregationTimeseriesDaoTest NPE by injecting the
direct executor into the spy.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The stack-based check in DefaultTbContext.input() only catches a loop
on the second Kafka round-trip through the same rule chain. When the
target rule chain equals the node's own rule chain (direct self-loop),
the first iteration is always unnecessary and should be rejected
immediately before any enqueue occurs.
Add an eager check in TbRuleChainInputNode.onMsg(): if the resolved
targetRuleChainId equals ctx.getSelf().getRuleChainId() (the rule chain
that contains this node), tellFailure() is called right away.
Together with the existing stack-based check in DefaultTbContext.input()
this forms a two-layer defence:
- Layer 1 (TbRuleChainInputNode): direct loops A→A, caught immediately
- Layer 2 (DefaultTbContext): indirect cycles A→B→A, caught on second pass
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
When a TbRuleChainInputNode has `forwardMsgToDefaultRuleChain=true` and the originator's
default rule chain is the same as the rule chain containing this node, the message enters
an infinite loop: the node forwards to the default rule chain, which routes back to the
same node, which forwards again, causing unbounded recursion and 100% CPU on rule-engine.
Fix: detect the loop in DefaultTbContext.input() by checking whether the calling rule node
is already present in the message's return stack (TbMsgProcessingCtx). On the second+
iteration the stack already contains the (ruleChainId, ruleNodeId) pair of the node,
so the call is a cycle. In that case tellFailure() is called with a descriptive message
and a WARN log is emitted instead of re-enqueuing the message.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
When agg=NONE (the default), findAllAsyncWithLimit() executed a
synchronous JPA query on the calling thread and wrapped the result in
Futures.immediateFuture(). Since this runs inside the access-validator
single-thread executor callback chain, a slow query blocks all other
telemetry and attribute requests.
Offload findAllAsyncWithLimit() to the JpaExecutorService work-stealing
pool via service.submit(), matching the pattern already used by
aggregated queries (findAndAggregateAsync).
Closes#15095
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Delay and deduplication rule nodes were creating brand new TbMsg objects
instead of copying the original, which reset the ruleNodeExecCounter to 0.
This allowed bypassing the maxRuleNodeExecutionsPerMessage limit.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Andrii Landiak
Sergey Matvienko
Maksym Tsymbarov
dashevchenko
Viacheslav Klimov
Vladyslav Prykhodko
Ekaterina Chantsova
Dmytro Khylko
Dmytro Skarzhynets
Dmytro Skarzhynets
nickAS21