Issues using MTLFence for VkSemaphore

Hello,
From what I understand, it seems the scopes for MTLFence and VkSemaphore are radically different.
The vulkan specs states that semaphore are intended for queue<->queue synchronization:

signaling a semaphore will include any command submitted in the queue before the signal operation as its source scope.
waiting on a semaphore will block all commands submitted in the queue after the wait operation

However, metal specs states that:

MTLFence is "An object that can capture, track, and manage resource dependencies across command encoders."
"Updates the given fence to capture all GPU work enqueued by the command encoder up to this specific point."
"Prevents further GPU commands from being enqueued by the command encoder until the given fence is reached."

So a MTLFence's scope only includes commands in the encoder where it's being signaled/waited upon.
This means that, if we have 3 encoders A, B and C, and a MTLFence signaled by A waited by B, we have the guarantee that B will execute after A is completed. But C is free to execute in parallel to both A and B (whereas a VkSemaphore would guarantee that both B and C would wait on A to complete).
Moreover, the current pattern to inject an empty blit encoder to wait or signal a semaphore means that signaling and waiting scope are empty, and are not actually synchronizing anything.
I'm assuming though that it has been tested and found to work on Mac at least. So I'd assume that Mac's GPU doesn't have (for now) the technical capability to do fine-grained encoder only scopes, and result in a MTLFence behaving like a MTLEvent. But this completely breaks on iOS (using iPhone XS 13.2.3).
By un-allowing VkSemaphore to use the MTLFence implementation, and reverting to the use of MTLEvent, the synchronization works as expected.
MTLFence however is appropriate to handle subpass synchronization inside a vk render pass, as it exactly matches VkSubpassDependency's semantic (assuming each subpass have its encoder).

@apayen

So a MTLFence's scope only includes commands in the encoder where it's being signaled/waited upon.

This does not appear to be the case. The old Apple Metal Programming Guide specifically includes examples discussing cross-encoder synchronization. And even the MTLFence description you quoted above includes "across command encoders".
It is, however, likely true that MTLFence does not support inter-queue sync.

the current pattern to inject an empty blit encoder to wait or signal a semaphore means that signaling and waiting scope are empty, and are not actually synchronizing anything

Can you clarify what you mean by this? Even though the new encoder itself is empty and has no scope itself, the command buffer should guarantee that the scope of any encoders before or after this empty encoder will be synchronized.
There was a lot of discussion about the use of MTLFence and MTLEvent to implement the synchronization of VkSemaphore. Definitely MTLEvent seems to be more suitable from a design perspective.
But one of the main drivers behind using MTLFence is that it seemed to be more stable under conditions here and here.
It may be that we need to figure out how to better make use of MTLEvent when it comes to VkSemaphore.
Currently, the use of either MTLFence or MTLEvent pass the same set of Vulkan CTS tests.
It would be very useful to find some solid test cases that would help us determine the stability of using MTLEvents for VkSemaphores.

So a MTLFence's scope only includes commands in the encoder where it's being signaled/waited upon.

What I meant by this is that the signal operation only wait for commands inside the signaling encoder to complete, and the wait operation only stall commands inside the waiting encoder. Of course, the signaling and waiting encoder are different encoders; hence the cross-encoder synchronization.

Even though the new encoder itself is empty and has no scope itself, the command buffer should guarantee that the scope of any encoders before or after this empty encoder will be synchronized.
This is what seems to be the wrong assumption.

Metal spec:

Updates the given fence to capture all GPU work enqueued by the command encoder up to this specific point
Prevents further GPU commands from being enqueued by the command encoder until the given fence is reached.
Apple does not use plural here.

This is further supported by the fact that, signaling/waiting MTLEvent must be done outside of any render encoder, which clearly indicates that all encoders before the event are required to complete before signaling, and all encoders after the event must wait.
On the other hand, MTLFence must be signaled/waited within a command encoder, which hints that the synchronization scope is indeed limited to that encoder (otherwise, it would be legal to signal/wait outside of an encoder as well).
Agreed that apple docs are not as explicit as vkspec, but there is no implicit guarantee that an encoder submitted after another will inherit its waiting fences.
From what I understand, the purpose of MTLFence is to create a graph of command encoders, similar to how vulkan render passes works: you can submit subpasses A B C D E F, and define dependencies A->B, B->F, C->D, D->F, E->F, would result in the following graph:
A->B-\
C->D-+->F
E----/

An order guarantee would turn this into (with C implicitly waiting on A due to A->B, and E implicitly waiting on C due to C->D)
A->B----\
   C->D-+->F
      E-/

Which greatly reduces the parallelism (though in this sample one could cleverly reorder and record E first - more complex graphs may be defined)

But one of the main drivers behind using MTLFence is that it seemed to be more stable under conditions here and here.
I have just found an issue (Acquiring a swapchain image not signaling the semaphore properly if the image is not readily available), for which I will open another issue. This could be linked to the GPU timeout issue.

Metal spec:

Updates the given fence to capture all GPU work enqueued by the command encoder up to this specific point

Prevents further GPU commands from being enqueued by the command encoder until the given fence is reached.

Notice that Apple does not use plural here.

However...the specs also say:

Fences are manipulated when the command buffer is submitted to the GPU. This maintains global order and prevents deadlock. Fences are evaluated at command encoder boundaries. Waits occur at the beginning of an encoder and updates occur at the end of the encoder.

AFAIK, the encoders are just a way to get the commands into the command buffer. In doing so they install the fences at the boundaries.
The command buffer itself ensures that commands are executed in order.

The promise upheld by Metal is that the perceived order in which commands are executed is the same as the way you ordered them.

So commands executed by one encoder (including the fence boundaries) should execute in order...and commands from prior encoders should be executed before a wait on a future encoder, and the commands in subsequent encoders should execute after an update on the fence at the tail of a previous encoder.
Commands in all prior encoders are in the scope of a wait on the current encoder...and commands in all subsequent encoders are in the scope of an update at the end of the current encoder.

Commands in all prior encoders are in the scope of a wait on the current encoder...and commands in all subsequent encoders are in the scope of an update at the end of the current encoder.

Sorry...I said that backwards...
Commands in the current and subsequent encoders are in the scope of a wait on the current encoder...and commands in the current and past encoders are in the scope of an update at the end of the current encoder.

Having said all this...if we can figure out what sometimes goes wrong with the MTLEvent implementation of VkSemaphore...I'd be happy to make MVK_ALLOW_METAL_EVENTS the default mechanism.

Having said all this...if we can figure out what sometimes goes wrong with the MTLEvent implementation of VkSemaphore...I'd be happy to make MVK_ALLOW_METAL_EVENTS the default mechanism.

I absolutely understand that you want to fix what is wrong with MTLEvent before reverting to using it, and support that.
The following is not to convince you to revert to MTLEvent straight away. But I think that, moving forward, it is critical to understand precisely what MTLFence does. Sadly Apple docs are not the best, hence the argument we're having.

The promise upheld by Metal is that the perceived order in which commands are executed is the same as the way you ordered them. While Metal might reorder some of your commands before processing them, this normally only occurs when there's a performance gain and no other perceivable impact.

What I understand here is that, for instance, blending would process in order, so that two alpha blended plane on top of each other are guaranteed to appear in the submission order. This guarantee is also provided by Vulkan.
However this guarantee is limited only to fragment ordering, not resource hazard, as hinted here

This forces the Gaussian blur filter [a compute encoder] to wait for the downsample filter [a blit encoder] to complete its work before beginning its own work. A waiting period is necessary because the Gaussian blur filter depends on dynamic texture data generated by the downsample filter. Without the fence, the GPU could execute both filters [encoders] in parallel, and thus read uninitialized dynamic texture data allocated from the heap.

This contradicts "this normally only occurs when there's a performance gain and no other perceivable impact." from the previous quote from Apple's doc, showing that perceived order does not apply here.
If there is a render encoder, followed by an empty blit encoder signaling a fence, the blit encoder is free to execute in parallel to the render encoder and signal the fence straightaway, without waiting for the render encoder to complete.
If there is a blit encoder waiting a fence, a render encoder that has been placed after is free to execute in parallel to the blit encoder (or even before). The render encoder has no reason to wait for a fence which is waited inside the blit encoder
If we have two render encoders, the perceived order guarantees would at best guarantee that, if they are rendering to the same targets, the blending would be ordered properly (to be confirmed though that the guarantee indeed works across encoders). But vertex (and fragment if not doing programmable blending) are free to be completely reordered/parallelized.

AFAIK, the encoders are just a way to get the commands into the command buffer.

They also define a synchronization scope for commands inside it. This is not explicitly said (curse Apple), but the API strongly suggests that:

An encoder has a begin, an end, and cannot be reused (this could be to force draws to have well defined state/bindings not impacted by previous encoder's state, but I think that's a side effect)
A render encoder requires the targets to be specified at creation time (begin) and cannot be changed. This forces the creation of a new scope when switching targets, which is exactly the behavior of vulkan render passes.
MTLFences are signaled/waited inside
MTLFences are signaled once and waited once, which gives a well defined dependency between exactly two encoder. (of course they can be reused when it can be proven that the next signal happens after the wait)
while MTLEvent are signaled/waited outside and do not enforce a well defined dependency. A fence can signal and wait any value in any order.

MTL describes MTLRenderCommandEncoder as

The object to use for encoding commands for a render pass.

If we consider a Render Encoder to be the equivalent of a Vulkan subpass, and MTLFence to be an execution dependency (between two subpasses), then all the API limitations makes a lot of sense.
https://www.khronos.org/registry/vulkan/specs/1.1/html/vkspec.html#renderpass

Execution of subpasses may overlap or execute out of order with regards to other subpasses, unless otherwise enforced by an execution dependency [which would be a MTLFence in metal]. Each subpass only respects submission order for commands recorded in the same subpass, and the vkCmdBeginRenderPass and vkCmdEndRenderPass commands that delimit the render pass - commands within other subpasses are not included [in submission order]. This affects most other implicit ordering guarantees.

Not being able to alter render targets within the same encoder, and being able to wait a MTLFence only at the beginning and signal it only at the end. It's almost a 1::1 mapping, except vulkan requires the full render passes and dependencies to be defined ahead of it's actual command encoding.

However this guarantee is limited only to fragment ordering, not resource hazard, as hinted here

This is because MTLHeaps default to MTLHazardTrackingModeUntracked.  MVK does not currently use anything with that hazard tracking mode, so MTLFences will not provide anything over the existing automatic hazard tracking (except additional unnecessary waiting).
I can confirm that MTLFences only apply to the current command encoder though.  I messed that up in PCSX2's renderer.  I had the following command buffers:

Vertex Upload command buffer.  Contains a blit encoder that copies vertex data from a CPU buffer to an untracked GPU buffer, then updates a MTLFence (goal is to make it so that even though the same buffer is being used for every draw, this upload can run on a DMA queue in parallel to any previous draws)
Draw command buffer.  Contains render encoders that consume the vertex data from (1).  The first (and only first) encoder on this buffer contains a wait on the MTLFence

Everything worked fine on Intel, Nvidia and AMD, where the GPU never reordered the encoders in (2), probably because they all transitively depended on the first encoder in their respective fragment shaders.  But when people started testing it on M1, which runs vertex shaders and fragment shaders separately, they got massive explosions of triangles across the whole screen.  Turns out it was moving all vertex shader runs from the draw command buffer that weren't in the first encoder ahead of the vertex upload.  Making every encoder in the draw command buffer wait for the fence fixed the issue.
So if we did want to use MTLFences and MTLHazardTrackingModeUntracked, we'd have to ensure every command buffer waited for a MTLFence associated with every previously-waited-on VkSemaphore (not just the most recent one), which sounds like a pain.  Probably better to just keep MTLHazardTrackingModeUntracked off where MTLEvent isn't available.


easy enablement for prometheus related feature

Summary
Easy enablement for prometheus feature by environment variables
Desired Behaviour
For sample as COUCHDB_USER, as a user, I want to enable prometheus related feature by environment value as
[prometheus]
additional_port = false
bind_address = <IP_ADDRESS>
port = 17986

prometheus_additional_port
prometheus_bind_address
prometheus_port
Possible Solution
Not sure if https://github.com/apache/couchdb/blob/main/configure#L247 this line is useless.
if not, take prometheus_port as sample:
{prometheus_port, $prometheus_port}

and in
rel/overlay/etc/default.ini
[prometheus]
additional_port = false
bind_address = <IP_ADDRESS>
port = {{prometheus_port}}

Additional context
N/A

as so far, with default value as configuration.
access:
/tmp % curl <IP_ADDRESS>:5984/_node/_local/_prometheus
{"error":"unauthorized","reason":"You are not a server admin or read-only metrics user"}

related with https://github.com/apache/couchdb/discussions/3935
I can understand we want to disable the prometheus by default, but...
as current status, the prometheus seems enabled at port 5984, and blocked prometheus as prometheus operator to access it.
are we want it disabled by default?
or
we'd better have a fixable configuration to control this feature enablement?
with my hands on, I am confusing.
attachment my yaml file for reference.
---
apiVersion: v1
kind: Service
metadata:
  name: org1peer1couchdb
spec:
  selector:
    app: org1peer1couchdb
  ports:
  - name: couchport
    port: 5984
    protocol: TCP
  - name: matrix
    port: 17986
    protocol: TCP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: org1peer1couchdb
spec:
  replicas: 1
  selector:
    matchLabels:
      app: org1peer1couchdb
  template:
    metadata:
      labels:
        app: org1peer1couchdb
    spec:
      containers:
      - name: couchdb
        image: couchdb:3.2
        imagePullPolicy: IfNotPresent
        env:
          - name: "COUCHDB_USER"
            value: "admin"
          - name: "COUCHDB_PASSWORD"
            value: "adminpw"
          - name: "PROMETHEUS_ADDITIONAL_PORT" # useless so far
            value: "true"
          - name: "PROMETHEUS_BIND_ADDRESS" # useless so far
            value: "<IP_ADDRESS>"
          - name: "PROMETHEUS_PORT" # useless so far
            value: "17986"
        ports:
            - containerPort: 5984
            - containerPort: 17986
---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: org1peer1couchdb
  namespace: default
  labels:
    release: mypro
spec:
  namespaceSelector:
    matchNames:
    - default
  selector:
    matchLabels:
      app:  org1peer1couchdb
  endpoints:
  - port: couchport
    path: /_node/_local/_prometheus


Repo sync for protected CLA branch

The pull request is created from main637952293803096420sync_temp to main to fix git push error for protected CLA branch

@opbld17 : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Carousel is not working for lower version of android phones

I'm using materializecss for my cordova project.
I'm using the carousel - it works great except for lower versions of android. I'm currently checking with android v4.2.
But error ReferenceError: requestAnimationFrame is not defined being thrown from the materiailize.js.
So I looked into materialize.js source code,  as requestAnimationFrame is undefined- tried with webkitRequestAnimationFrame  wherever the requestAnimationFrame is being used - then it started working in androind 4.2. I think this is the issue with backward compatibility.

Any work around to make it work, without editing the materiaize.js file?

Added a polyfill in 0e76801.
Can you try this latest commit and let me know if it works?


Create 7-Emoji.mdx

The metals and octocat emoji are not displayed on the deployment. How can that be fixed?

Good idea, but not every markdown processor supports emojis, and they're not used much in documentation, so I think it's better without

Ohh, okay, sure!


feat(kousa): implemented ip address hashing, fix tests, etc.

this pr implements the hashing of ip addresses that are stored in the database and fixes kousa tests.
implements #2579

please don't use npm on kebab, we use yarn for almost all of our workspaces. also delete the package-lock.json

Remove Session.vim file

Lol I already told him to do that

closing because stale ig


Ingress proxy memory usage possible regression for 1.7.4

In the release qualification test, found out that the ingress proxy memory usage has gone up to around 240M from 130M after upgrading to 1.7.4 from 1.7.3, but the memory usage increase is normal overtime, no apparent leak observed. And didn't see similar regression on the workload proxies. Check the below links for accessing prometheus/grafana running on the clusters for more details.
prometheus_on_1.7.4
grafana_on_1.7.4
As comparison: prometheus_on_master

heap size goes up, but alloc goers down: http://prom.release-qual-17.qualistio.org/graph?g0.range_input=2d&g0.expr=container_memory_working_set_bytes{container%3D"istio-proxy"%2Cnamespace%3D"istio-system"}&g0.tab=0&g1.range_input=2d&g1.expr=envoy_server_memory_allocated{namespace%3D"istio-system"}&g1.tab=0&g2.range_input=2d&g2.expr=envoy_server_memory_heap_size{namespace%3D"istio-system"}&g2.tab=0
@lambdai does this version have the heap compacting?

checking the same test with 1.7.4 on another cluster: oss17-stable-iamwen in the mixologist project and did not see similar result as here so far, would continue monitor these clusters.

heap size ~= 1.5x allocated
It is not too bad.
The compaction cannot squeeze heap size  to allocated due to fragments and cache. Cache is the "C" in tCmalloc)

so, what's the decision? 1.7.4 is good to go?

Did more investigation with @lambdai with profiling and running more tests on other clusters but didn't see similar situation. Ingress mem usage on another 1.7 cluster and master cluster is normal. Another observation is that the memory usage value is really unstable in this cluster and seems not related to QPS size as well(adjusted the QPS or even created some random 500 errors but mem size didn't change accordingly). So in summary I think it is more like a special case but I will continue to investigate.
Therefore for 1.7.4, @jwendell @JimmyCYJ @Mythra I think it is good to go.

Awesome, thanks!

Possibly related: https://github.com/istio/istio/issues/28652


CCM project updates 1-30

Issue #, if available:
Description of changes:
CCM project updates 1-30
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm

/approve


Bug: " displays as "

If you type a quotation mark you get the HTML Entity equivalent of it.

Duplicate of #172


refactor: Minor optimization and fixes

No major changes, just cleanups.

@Totodore Thanks for accepting this pr 😄


Exclude QUEUE tables from snapshoting

Impact

[ ] Bug fix (non-breaking change which fixes expected existing functionality)
[X] Enhancement/New feature (adds functionality without impacting existing logic)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

@hel1e here is the fix that you pointed out on https://github.com/liquibase/liquibase/pull/5087#discussion_r1378075792

Great, thanks for the quick response 😊
With regards
Helene Brinchmann Halvorsen
DIPS AS
Fra: filipe @.>
Sendt: mandag 6. november 2023 20:39
Til: liquibase/liquibase @.>
Kopi: Helene Brinchmann Halvorsen @.>; Mention @.>
Emne: Re: [liquibase/liquibase] Exclude QUEUE tables from snapshoting (PR #5166)
@hel1ehttps://github.com/hel1e here is the fix that you pointed out on #5087 (comment)https://github.com/liquibase/liquibase/pull/5087#discussion_r1378075792
—
Reply to this email directly, view it on GitHubhttps://github.com/liquibase/liquibase/pull/5166#issuecomment-1796177601, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A7XAFS5HL64INQILTUFN7ZLYDE4ELAVCNFSM6AAAAAA7ABDTEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJWGE3TONRQGE.
You are receiving this because you were mentioned.Message ID: @.***>


Add single query to detect presence of offline data

In an app that supports offline mode, it is arguably good practice/UX  to visually indicate that there is offline data.
Whilst you can do: " MyResource.$writes.queue.length"   for each different cached resource, this is a bit ugly (see my updated to #24 that $writes.count appears not to work)
I think it would be nice if you could do $cachedResource.numOfflineUpdates() and it return a number of the total write queues across all models.
If it is thought worthwhile I am happy to have a go at implementing.

Looking for the same thing here, I didn't succeed yet.
BTW thank you for this awesome library :+1:


az aks check-acr

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az aks check-acr
Errors:
The command failed with an unexpected error. Here is the traceback:
'serverVersion'
Traceback (most recent call last):
  File "/opt/az/lib/python3.6/site-packages/knack/cli.py", line 231, in invoke
    cmd_result = self.invocation.execute(args)
  File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 658, in execute
    raise ex
  File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 721, in _run_jobs_serially
    results.append(self._run_job(expanded_arg, cmd_copy))
  File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 692, in _run_job
    result = cmd_copy(params)
  File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 328, in __call__
    return self.handler(*args, **kwargs)
  File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/command_operation.py", line 121, in handler
    return op(**command_args)
  File "/opt/az/lib/python3.6/site-packages/azure/cli/command_modules/acs/custom.py", line 1649, in aks_check_acr
    kubectl_version["serverVersion"]["minor"])
KeyError: 'serverVersion'

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az aks check-acr --name {} --resource-group {} --acr {}

Expected Behavior
Environment Summary
Linux-5.4.0-1070-azure-x86_64-with-debian-10.2 (Cloud Shell), Common Base Linux Delridge (quinault)
Python 3.6.10
Installer: DEB

azure-cli 2.33.1

Extensions:
azure-devops 0.20.0
ai-examples 0.2.5
ssh 1.0.0

Dependencies:
msal 1.16.0
azure-mgmt-resource 20.0.0

Additional Context

route to CXP team

@heyitsmekishore Apologies for the delay, we are looking into it. In the meantime, can you upgrade your az cli to latest version?

Yes, everything is fine.
On Mon, May 23, 2022, 19:31 msftbot[bot] @.***> wrote:

Hi, we're sending this friendly reminder because we haven't heard back
from you in a while. We need more information about this issue to help
address it. Please be sure to give us your input within the next 7 days.
If we don't hear back from you within 14 days of this comment the issue
will be automatically closed. Thank you!
—
Reply to this email directly, view it on GitHub
https://github.com/Azure/azure-cli/issues/21461#issuecomment-1134717618,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANQAFS7L6MZVTODXA24SRTTVLOFSNANCNFSM5PRJZJSA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Thank you for the confirmation @heyitsmekishore


SD: add y3mesh handling to glue code

THIS PULL REQUEST IS READY TO MERGE
Feature or improvement description
I continued the y3mesh updates through the glue code.  The regression tests all appear to pass.
This should be reviewed before merging to make sure I did not miss anything in the glue code.

Once this is merged, I think we can make a PR from this branch directly to the main repo dev branch.
I will propagate these changes through the relevant branches to get it to the spiderflowt branch (SrvD linearization, and MD linearization are affected).

maybe @jjonkman can review


Fixed Hashmap Key value comparision

Description
The PR fixes the following tests which could produce non-deterministic/flaky pass/fail result
com.cloud.network.as.AutoScaleVmProfileVOTest#tstSetOtherDeployParamsForUpdate
com.cloud.network.as.AutoScaleVmProfileVOTest#testCounterParamsForUpdate
Setup:
Java version: <IP_ADDRESS>
Maven version: 3.8.8
Test failure reproduction:
The tests compares the keys and values of hashmap (based on index) with hardcoded string and asserts if they are equal. However, the order of key value pairs within hashmap is not gauranteed. Hence the test can fail. This issue was verified using the NonDex plugin.
Steps
git clone https://github.com/apache/cloudstack.git
cd cloudstack
mvn install -pl engine/schema -am -DskipTests
mvn -pl engine/schema edu.illinois:nondex-maven-plugin:2.1.1:nondex -Dtest=com.cloud.network.as.AutoScaleVmProfileVOTest#tstSetOtherDeployParamsForUpdate

Root cause and fix
Test Failue in Nondex Mode
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.068 s <<< FAILURE! - in com.cloud.network.as.AutoScaleVmProfileVOTest
[ERROR] tstSetOtherDeployParamsForUpdate(com.cloud.network.as.AutoScaleVmProfileVOTest)  Time elapsed: 0.061 s  <<< FAILURE!
org.junit.ComparisonFailure: expected:<[serviceofferingid]> but was:<[rootdisksize]>
	at com.cloud.network.as.AutoScaleVmProfileVOTest.tstSetOtherDeployParamsForUpdate(AutoScaleVmProfileVOTest.java:72)

[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   AutoScaleVmProfileVOTest.tstSetOtherDeployParamsForUpdate:72 expected:<[serviceofferingid]> but was:<[rootdisksize]>
[INFO]

The above error occurs when comparing the keys and values of a Hashmap. The expected string is a hardcoded key/value pair. The actual string is derived by parsing the hashmap and get the key by index. The comparision fails in some cases because the hashmap does not maintain order of contents.
Fix
The Fix implements a custom method 'Contains pair' to check if otherDeployParamsList contains the specific key and value pairs. If the List contains the specific key value pairs, It return true. This ensures that assertion does not consider the order of contents in Hashmap.
Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[X] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)
[ ] build/CI

Feature/Enhancement Scale or Bug Severity
This code modifies only test files and should not affect anything in production
Feature/Enhancement Scale

[ ] Major
[X] Minor

Bug Severity

[ ] BLOCKER
[ ] Critical
[ ] Major
[X] Minor
[ ] Trivial

How Has This Been Tested?
The test passes when run with the NonDex tool after the implementation of the fix. (mvn -pl engine/schema edu.illinois:nondex-maven-plugin:2.1.1:nondex -Dtest=com.cloud.network.as.AutoScaleVmProfileVOTest#tstSetOtherDeployParamsForUpdate)
How did you try to break this feature and the system with this change?
The change only creates a new test utility and calls it within a single test. Hence it should not affect any other code

I do not know anyone has faced the test failures, at least I never did.
anyway,  using LinkedHashMap is a more simple fix.

I do not know anyone has faced the test failures, at least I never did.
anyway, using LinkedHashMap is a more simple fix.

I utilized a helper function 'containsPair' because setOtherDeployParamsForUpdate in main expects a Hashmap and I wanted to minimize the changes in the main function. However, I am open to modifying it as well. Please let me know.
https://github.com/apache/cloudstack/blob/be4a648f5ab708233267ced9eaa943c12f87697c/engine/schema/src/main/java/com/cloud/network/as/AutoScaleVmProfileVO.java#L171-L174

never seen this error either. I'm not sure if the order is guaranteed in the core code, but the change would not hurt if it doesn't help.


scrolling - should animate - not able to configure scroll speed

With the $ionicScrollDelegate, the scroll methods have a shouldAnimate property.
However, it is not possible to configure the scroll speed. Looking at the source code of the scrollViewNative it is hard-coded to 250ms. I'd like to be able to change that to e.g. 500ms.

I found a solution :) http://stackoverflow.com/questions/29742525/ionic-decrease-scroll-speed

However, this does not work in the native scroll... Only in JS scroll. So is it possible to make it available in native scroll?

Hello! Thanks for opening an issue with us! Since this is more of a question you will get a better answer over at our forum (https://forum.ionicframework.com/) or on our slack channel (http://ionicworldwide.herokuapp.com/) Thanks Again!


Release 1.0-alpha-1

Jenkins core 2.239 is released, so this theme is no usable with Weekly releases. I suggest releasing the 1.0-alpha-1 version so that we pin the current theme and keep doing changes incrementally with a changelog.
WDYT @timja @fqueiruga ?

Released https://github.com/jenkinsci/dark-theme/releases/tag/0.0.1


Remove posterior_probabilities parameter.

This PR removes the posterior_probabilities parameter, only using the percolator. #448

PR checklist

[ ] This comment contains a description of changes (with reason).
[ ] If you've fixed a bug or added code that should be tested, add tests!
[ ] If you've added a new tool - have you followed the pipeline conventions in the contribution docs
[ ] If necessary, also make a PR on the nf-core/quantms branch on the nf-core/test-datasets repository.
[ ] Make sure your code lints (nf-core lint).
[ ] Ensure the test suite passes (nextflow run . -profile test,docker --outdir <OUTDIR>).
[ ] Check for unexpected warnings in debug mode (nextflow run . -profile debug,test,docker --outdir <OUTDIR>).
[ ] Usage Documentation in docs/usage.md is updated.
[ ] Output Documentation in docs/output.md is updated.
[ ] CHANGELOG.md is updated.
[ ] README.md is updated (including new tool citations and authors/contributors).

This module coud be removed when keep only percolator https://github.com/bigbio/quantms/tree/master/modules/local/openms/idpep

This module could be removed when keeping only percolator https://github.com/bigbio/quantms/tree/master/modules/local/openms/idpep https://github.com/bigbio/quantms/tree/master/modules/local/openms/falsediscoveryrate

Should I remove it? @jpfeuffer @daichengxin? If you give me a 👍, I will in the same PR.

Not sure if FDR can be removed. It needs to be recalculated after ConsensusID

Not sure if FDR can be removed. It needs to be recalculated after ConsensusID

Only IDPEP can be removed FDR is used all over the place.

@jpfeuffer @timosachsenberg @daichengxin Just remove also IDPEP as requested.

@jpfeuffer @timosachsenberg @daichengxin can you review this PR, and accept it 😉


Update testing-library packages for cra-template

Describe the bug
The following package.json files need dependencies updated:

https://github.com/facebook/create-react-app/blob/94932bedc09976aeac43615d95906aa2dcfefa1f/packages/cra-template/template.json
https://github.com/facebook/create-react-app/blob/94932bedc09976aeac43615d95906aa2dcfefa1f/packages/cra-template-typescript/template.json

And the template code should be changed to use screen:
https://github.com/facebook/create-react-app/blob/8a1ee2f7a531d83cb76cc882d1e346c5cdd55f56/packages/cra-template-typescript/template/src/App.test.tsx
  import React from 'react';
- import { render } from '@testing-library/react';
+ import { render, screen } from '@testing-library/react';
  import App from './App';

  test('renders learn react link', () => {
-   const { getByText } = render(<App />);
-   const linkElement = getByText(/learn react/i);
+   render(<App />);
+   const linkElement = screen.getByText(/learn react/i);
    expect(linkElement).toBeInTheDocument();
  });

And the same treatment for this one:
https://github.com/facebook/create-react-app/blob/2de57fe15a69a84fadb08ce549599c7de5a9d3b2/packages/cra-template/template/src/App.test.js
I think the rest of the template is irrelevant.

In order to update the dependencies, the templates needs Node 10+.
Right now they're supporting Node 8 (cra-template) & Node 8.10 (cra-template-typescript).
https://github.com/facebook/create-react-app/blob/d2f813f8897ffcd2f0b0d2da75d0c44924c92f4d/packages/cra-template/package.json#L17-L19
https://github.com/facebook/create-react-app/blob/d2f813f8897ffcd2f0b0d2da75d0c44924c92f4d/packages/cra-template-typescript/package.json#L18-L20

Ah yeah, it would be great if we drop node 8 so we can upgrade jest as well :)

Jest upgrade is happening in #8362

@ianschmitz Not all of this is done, so this one should be re-opened I think 🙂

We won't drop Node 8 until v4, and will review/update all packages at that time.

Sounds reasonable 👍


PySpark kernel

This PR also moves from using RH SCL to EPEL repo on the hedge that this is closer to the likely deployment environment of EMR.
The overall strategy is to make this base container that can be extended by something like https://github.com/locationtech-labs/geopyspark which will add the required application dependencies.

I can abide this.  Like to see the move away from SCL, which was a pain.  Like that the build.sh script was broken up.  Never approved of the undermining of the Docker caching system that it represented.  Conditional +1 predicated on the response to the Python 3.5 question in the comments above.


PowerRename doesn't have $0 (complete match contents) capturing group.

ℹ Computer information

PowerToys version: v0.29.3
PowerToy Utility: PowerRename
Running PowerToys as Admin: No
Windows build number: 20H2 (OS Build 19042.746)

📝 Provide detailed reproduction steps (if any)
See (expected) saved regex behaviour on regex101: https://regex101.com/r/46Ffqa/1
See the result we get with PowerRename

✔ Expected result
We should expect that $0 should return a string with the complete match result from the regex.
❌ Actual result
$0 doesn't do anything
📷 Screenshots
See above
An aside
It might be useful to quickly go through all of the 'Quick Reference' syntax listed on regex101 and make a table for what is / isn't currently supported.
Also, Microsoft VS Code does support this regex syntax (and perhaps more than PowerRename) - Why not just steal VS Code's search and replace engine (dropping support for invalid windows filename characters like \n) rather than going through the same pain that VS Code had to go through to offer a full regex solution?

I've since found out that PowerRename supports $& instead of $0. Whereas both regex101 and VSCode use $0 instead of $&.

I've since found out that PowerRename supports $& instead of $0. Whereas both regex101 and VSCode use $0 instead of $&.


JOSS Review: Difficulties with Installation and CUDA Compilation Error

I am currently reviewing the smite code for JOSS and encountered several issues during the installation and setup. Here are the details:

Installation Steps: The installation process could be made more straightforward. Currently, after cloning the repository, there's an additional step to compile mex files and possibly the CUDA files, depending on the machine's architecture. This step is not particularly intuitive, especially for newcomers or users unfamiliar with MATLAB's mexing process.

CUDA Compilation Error: While attempting to compile the CUDA files, I encountered the following error multiple times:
 nvcc fatal   : Cannot find compiler 'cl.exe' in PATH
This error appeared when trying to compile smi_cuda_gaussMLEv2, smi_cuda_FindROI, and smi_cuda_PSFSample3DBlob. I'm using MATLAB R2022b on Windows 11 with NVIDIA GeForce RTX 3090 (ComputeCapability: '8.6').

Recommendations:

Consider improving the installation instructions to make them more intuitive, potentially with an automated script.
For the CUDA error, it seems like the compiler cannot find 'cl.exe'. This might be related to the setup of the CUDA environment and the Visual Studio installation. Ensure that the necessary compilers are correctly set in the PATH or provide clear instructions for users on how to do this.

Thank you for your attention to these issues. I look forward to seeing the improvements and continuing with the review.

Thank you for your comments.  First of all, the distribution contains compiled versions of the mex codes for Linux and Windows (I just added MacOS), all 64 bit, as well as the CUDA codes (the ptx files are a low level architecture independent format), but this is not clear from the instructions, I agree.  In theory, most users should not have to compile anything by hand.  The installation instructions have been reorganized and expanded to make this clearer.
With regards to the error with cl.exe, the PATH in Windows must contain the directory of binaries for the NVIDIA GPU Computing Toolbox AND for the Visual Studio installation (where cl.exe is located), examples of which are provided in cuda_Make.  The instructions in cuda_Make have been expanded.

Thank you for your comments.  I apologize for the delay in responding as your issues prompted further examination on our own about how to handle them, especially CUDA.
First of all, the distribution contains compiled versions of the mex codes for Linux and Windows (I just added MacOS), all 64 bit, as well as the CUDA codes (the ptx files are a low level architecture independent format), but this is not clear from the instructions, I agree.  In theory, most users should not have to compile anything by hand.  The installation instructions have been reorganized and expanded to make this clearer.  The make scripts have also been more heavily commented.
It is not so easy to make the installation process completely automated, especially for Windows, if recompilation is needed (which should be rare; we did test SMITE on various machines with compute capability 5.0 to 8.6 using the updated mex and ptx files that are provided in the development version).  We will continue to make the installation process clearer, but each machine is different, so especially with CUDA + Visual Studio, it is hard to generalize. However, MATLAB is making mex file setup nearly automatable, so hopefully they will do the same for CUDA.
With regards to the error with cl.exe, the PATH in Windows must contain the directory of binaries for the NVIDIA GPU Computing Toolbox AND for the Visual Studio installation (where cl.exe is located), examples of which are provided in cuda_Make.  Also, you need relatively new versions of the CUDA driver (we tried 11.7 and 12.2) and Visual Studio (2019
community worked for us).  Again, most users will be able to used the compiled files unchanged as is the case at
our university.

Thank you for clarifying the installation process and addressing the CUDA issues. I've checked the updates, and the issue is now resolved. Thanks for your quick action.


GPU shared memory causing slow PyTorch training

Windows Version
Microsoft Windows [Version 10.0.22621.2215]
WSL Version
WSL version: <IP_ADDRESS>
Are you using WSL 1 or WSL 2?

[X] WSL 2
[ ] WSL 1

Kernel Version
<IP_ADDRESS>
Distro Version
Ubuntu 20.04
Other Software
PyTorch 2.0.1
Repro Steps
Run a PyTorch training job that repeatedly allocates close to the max physical VRAM available on an attached Nvidia GPU. The issue occurs both when the GPU is the primary display GPU and when it is not (this system has a 3080 and 3090 of which the 3080 drives the displays).
Expected Behavior
I expect similar it/s to before I installed some OS and driver updates and low usage of the GPU BUS and shared memory.
Actual Behavior
However, instead the GPU utilization is pinned to 100%, BUS usage spikes much higher than normal, GPU temps stay low, shared GPU memory spikes from it's normally near-zero value and training occurs at a snails pace. Reducing the batch size by one resolves this issue.
Example:

Diagnostic Logs
No response
Edit:
It appears some people on Reddit running into the same issue are blaming recent Nvidia driver updates: https://www.reddit.com/r/LocalLLaMA/comments/14fb9c0/last_nvidia_drivers_let_you_use_the_shared_memory/
Is this still the most relevant place to post this?

Unfortunately if the issue comes from an nvidia driver update, this isn't something that WSL can fix. I'd recommend raising the issue to nvidia directly.

I can confirm that using WSL 2 with pytorch to run a LLama2 model is even slower than running it on CPU.
My hardware:
Windows 11
CPU: 7945HX,
GPU: RTX 4060 mobile with 8 GB of dedicated memory, 45 GB of shared GPU memory
Mem: 96 GB ddr5
result:
GPU usage is 100% but power consumption is very low: 15w out of 140W
The generation process took forever to run.


[BUG] No signal to coreMQTT-Agent network manager that OTA job has stopped, once OTA is successful

Describe the bug
After OTA job is finished and new firmware is verified successfully, there is no signal to  coreMQTT-Agent network manager that an OTA job has stopped.
The signal is released only if OtaJobEventFail
        case OtaJobEventFail:
            ESP_LOGI( TAG, "Received an OtaJobEventFail notification from OTA Agent." );

            /* Signal coreMQTT-Agent network manager that an OTA job has stopped. */
            xCoreMqttAgentManagerPost( CORE_MQTT_AGENT_OTA_STOPPED_EVENT );
            break;

System information

Hardware board: ESP32
IDE used: IDF 5.1
Operating System: Windows
Code version: v202212.00-50-ge2d407f
Project/Demo: iot-reference-esp32c3
If your project is a custom application, please add the relevant code snippet(s) in the section titled "Code to reproduce bug".

Expected behavior
After OtaJobEventStartTest is done and image validation is finished there should be signal xCoreMqttAgentManagerPost(CORE_MQTT_AGENT_OTA_STOPPED_EVENT)
like this:
  case OtaJobEventStartTest:

    /* This demo just accepts the image since it was a good OTA update and
     * networking and services are all working (or we would not have made it
     * this far). If this were some custom device that wants to test other
     * things before validating new image, this would be the place to kick off
     * those tests before calling OTA_SetImageState() with the final result of
     * either accepted or rejected. */

    ESP_LOGI(TAG, "Received OtaJobEventStartTest callback from OTA Agent.");

    err = OTA_SetImageState(OtaImageStateAccepted);

    if (err == OtaErrNone) {
      ESP_LOGI(TAG, "New image validation succeeded in self test mode.");
    } else {
      ESP_LOGE(TAG, "Failed to set image state as accepted with error %d.",
               err);
    }
    xCoreMqttAgentManagerPost(CORE_MQTT_AGENT_OTA_STOPPED_EVENT);
    break;

and only after this flag other tasks can start their activity again.
Actually based on FreeRTOS documentation there should be one more case OtaJobEventUpdateComplete = 7, but I can't find this event in : https://github.com/FreeRTOS/iot-reference-esp32c3/blob/main/main/demo_tasks/ota_over_mqtt_demo/ota_over_mqtt_demo.c#L516-L609
typedef enum OtaJobEvent
{
    OtaJobEventActivate = 0,       /*!< @brief OTA receive is authenticated and ready to activate. */
    OtaJobEventFail = 1,           /*!< @brief OTA receive failed. Unable to use this update. */
    OtaJobEventStartTest = 2,      /*!< @brief OTA job is now in self test, perform user tests. */
    OtaJobEventProcessed = 3,      /*!< @brief OTA event queued by OTA_SignalEvent is processed. */
    OtaJobEventSelfTestFailed = 4, /*!< @brief OTA self-test failed for current job. */
    OtaJobEventParseCustomJob = 5, /*!< @brief OTA event for parsing custom job document. */
    OtaJobEventReceivedJob = 6,    /*!< @brief OTA event when a new valid AFT-OTA job is received. */
    OtaJobEventUpdateComplete = 7, /*!< @brief OTA event when the update is completed. */
    OtaLastJobEvent = OtaJobEventStartTest
} OtaJobEvent_t;

Additional question
In case OtaJobEventSelfTestFailed OTA_Shutdown is executed, should program also trigger xCoreMqttAgentManagerPost(CORE_MQTT_AGENT_OTA_STOPPED_EVENT); in that case or ot will be covered by
OtaJobEventFail any way?
        case OtaJobEventSelfTestFailed:
            ESP_LOGI( TAG, "Received OtaJobEventSelfTestFailed callback from OTA Agent." );

            /* Requires manual activation of previous image as self-test for
             * new image downloaded failed.*/
            ESP_LOGE( TAG, "OTA Self-test failed for new image. shutting down OTA Agent." );

            /* Shutdown OTA Agent, if it is required that the unsubscribe operations are not
             * performed while shutting down please set the second parameter to 0 instead of 1. */
            OTA_Shutdown( 0, 1 );

            break;

Screenshots or console output
Sorry, I didn't record console output for that case. How ever after sucessful OTA update other task kept beeing inactive. And only way to recover from this stage was to manually reboot the device

@NightSkySK Thanks for the bug report. We will look into it.

@paulbartell Did you managed to look or replicate this issue

Is the same thing I am seeing. I have successfully run the OTA update, but the AWS Jobs console always reports it as a failure, as the expected "SUCCESS" update to job/{job_id}/update never happens. This can be seen here:
I (188594) AWS_OTA: Signature verification succeeded.
I (188594) AWS_OTA: Received entire update and validated the signature.
I (188964) MONKEY_AWS_IOT_JOBS_TASK:  Received: 306   Queued: 306   Processed: 305   Dropped: 0
I (188994) coreMQTT: Publishing message to $aws/things/S900001/jobs/AFR_OTA-vdsgfsdfga/update.

I (189964) MONKEY_AWS_IOT_JOBS_TASK:  Received: 306   Queued: 306   Processed: 305   Dropped: 0
I (190614) coreMQTT: Ack packet deserialized with result: MQTTSuccess.
I (190614) coreMQTT: State record updated. New state=MQTTPublishDone.
I (190614) MONKEY_AWS_IOT_JOBS_TASK: Sent PUBLISH packet to broker $aws/things/S900001/jobs/AFR_OTA-vdsgfsdfga/update to broker.

I (190614) coreMQTT: De-serialized incoming PUBLISH packet: DeserializerResult=MQTTSuccess.
W (190624) MONKEY_AWS_IOT_JOBS_TASK: Payload: {"status":"IN_PROGRESS","statusDetails":{"self_test":"ready","updatedBy":"0x01050009"}}

I (190634) coreMQTT: State record updated. New state=MQTTPublishDone.
I (190654) MONKEY_AWS_IOT_JOBS_TASK: Received OtaJobEventActivate callback from OTA Agent.
I (190654) MONKEY_AWS_IOT_JOBS_TASK: Received update response: $aws/things/S900001/jobs/AFR_OTA-vdsgfsdfga/update/accepted.
I (190664) esp_image: segment 0: paddr=00200020 vaddr=3f400020 size=3b2b0h (242352) map
I (190724) esp_image: segment 1: paddr=0023b2d8 vaddr=3ff80064 size=0002ch (    44)
I (190734) esp_image: segment 2: paddr=0023b30c vaddr=3ffbdb60 size=04d0ch ( 19724)
I (190744) esp_image: segment 3: paddr=00240020 vaddr=400d0020 size=d7ce0h (883936) map
I (190894) esp_image: segment 4: paddr=00317d08 vaddr=3ffc286c size=00c88h (  3208)
I (190894) esp_image: segment 5: paddr=00318998 vaddr=40080000 size=18d64h (101732)
I (190924) esp_image: segment 6: paddr=00331704 vaddr=400c0000 size=00064h (   100)
I (190924) esp_image: segment 7: paddr=00331770 vaddr=50000000 size=00028h (    40)
I (190924) esp_image: segment 0: paddr=00200020 vaddr=3f400020 size=3b2b0h (242352) map
I (190964) MONKEY_AWS_IOT_JOBS_TASK:  Received: 306   Queued: 306   Processed: 306   Dropped: 0
I (190974) esp_image: segment 1: paddr=0023b2d8 vaddr=3ff80064 size=0002ch (    44)
I (190984) esp_image: segment 2: paddr=0023b30c vaddr=3ffbdb60 size=04d0ch ( 19724)
I (190984) esp_image: segment 3: paddr=00240020 vaddr=400d0020 size=d7ce0h (883936) map
I (191144) esp_image: segment 4: paddr=00317d08 vaddr=3ffc286c size=00c88h (  3208)
I (191144) esp_image: segment 5: paddr=00318998 vaddr=40080000 size=18d64h (101732)
I (191164) esp_image: segment 6: paddr=00331704 vaddr=400c0000 size=00064h (   100)
I (191174) esp_image: segment 7: paddr=00331770 vaddr=50000000 size=00028h (    40)
I (191754) wifi:state: run -> init (0)
I (191754) wifi:pm stop, total sleep time: 92504243 us / 177986771 us

I (191754) wifi:<ba-del>idx:0, tid:0
I (191754) wifi:new:<12,0>, old:<12,0>, ap:<255,255>, sta:<12,0>, prof:1
E (191764) wifi:NAN WiFi stop
I (191764) core_mqtt_agent_manager: WiFi disconnected.
I (191764) monkey_wifi.c: * WIFI_EVENT : SYSTEM_EVENT_STA_DISCONNECTED
W (191774) monkey_wifi.c: Disconnect code   : 8
I (191774) monkey_wifi.c: Network Unavailable
E (191784) monkey_wifi.c: Disconnect reason : WIFI_REASON_UNSPECIFIED
E (191784) monkey_wifi.c: monkey task fsm -> MONKEY_WIFI_DISCONNECTING
I (191794) monkey_wifi.c: * WIFI_EVENT : SYSTEM_EVENT_STA_STOP
W (191804) monkey_wifi.c: Uptime = 191 s
W (191814) monkey_wifi.c: Uptime = 0 hrs
E (191814) monkey_wifi.c: Entering monkey_reconnect
I (191864) wifi:flush txq
I (191864) wifi:stop sw txq
I (191864) wifi:lmac stop hw txq
ets Jul 29 2019 12:21:46

The last thing AWS hears is that the job is still in progress!

I've finally found some time to catch the exact logs of the situation which I've observed.
Full log:
log.mSpaceGate.20240302140851.txt
Initial device configuartion:
I (871) App_Version: Version: t0.2.4
I (871) App_Version: Project Name: mSpaceGate
I (871) App_Version: Compile Time: 13:31:44
I (881) App_Version: Compile Date: Mar  2 2024
I (881) App_Version: SOFTWARE VERSION: 0.2.4
I (911) ota_over_mqtt: OTA over MQTT demo, Application version 0.2.4

Once new job is received the other task are suspended (OTA started. Preventing coreMQTT-Agent commands from being enqueued.)as expected:
I (17291) ota_over_mqtt: Received job message callback, size 492.
I (17301) AWS_OTA: Extracted parameter: [key: value]=[execution.jobId: AFR_OTA-mSpaceGate_t0_2_5]
I (17311) AWS_OTA: Extracted parameter: [key: value]=[execution.jobDocument.afr_ota.streamname: AFR_OTA-a5ccc605-4e35-4db8-a17f-ed918d372f7c]
I (17331) AWS_OTA: Extracted parameter: [key: value]=[execution.jobDocument.afr_ota.protocols: ["MQTT"]]
I (17341) AWS_OTA: Extracted parameter: [key: value]=[filepath: /]
I (17341) AWS_OTA: Extracted parameter: [key: value]=[filesize: 1312496]
I (17351) AWS_OTA: Extracted parameter: [key: value]=[fileid: 0]
I (17361) AWS_OTA: Extracted parameter: [key: value]=[certfile: Code Verify Key]
I (17361) AWS_OTA: Extracted parameter [ sig-sha256-ecdsa: MEUCIQDsSDL3R+0JJpIK0HfC/mrhfjg1... ]
I (17371) AWS_OTA: Job document was accepted. Attempting to begin the update.
I (17381) AWS_OTA: Job parsing success: OtaJobParseErr_t=OtaJobParseErrNone, Job name=AFR_OTA-mSpaceGate_t0_2_5
I (17391) ota_over_mqtt: Received OtaJobEventReceivedJob callback from OTA Agent.
I (17401) AWS_OTA: otaPal_GetPlatformImageState
I (17401) report: OTA started. Preventing coreMQTT-Agent commands from being enqueued.
I (17401) esp_ota_ops: aws_esp_ota_get_boot_flags: 1
I (17411) sub_pub_unsub: OTA started. Preventing coreMQTT-Agent commands from being enqueued.
I (17421) esp_ota_ops: [0] aflags/seq:0x2/0x1, pflags/seq:0xffffffff/0x0
I (17431) core_mqtt_agent_manager: OTA started.

After new firmware is fully downloaded device reboot already with new SW version (App version:      t0.2.5):
I (225191) AWS_OTA: Number of blocks remaining: 1
I (225191) ota_over_mqtt: OTA Event processing completed. Freeing the event buffer to pool.
I (225201) AWS_OTA: Current State=[WaitingForFileBlock], Event=[ReceivedFileBlock], New state=[WaitingForFileBlock]
I (226171) coreMQTT: Publishing message to $aws/things/GA913F0001/streams/AFR_OTA-a5ccc605-4e35-4db8-a17f-ed918d372f7c/get/cbor.

I (226171) ota_over_mqtt: Sent PUBLISH packet to broker $aws/things/GA913F0001/streams/AFR_OTA-a5ccc605-4e35-4db8-a17f-ed918d372f7c/get/cbor to broker.

I (226191) AWS_OTA: Published to MQTT topic to request the next block: topic=$aws/things/GA913F0001/streams/AFR_OTA-a5ccc605-4e35-4db8-a17f-ed918d372f7c/get/cbor
I (226201) AWS_OTA: Current State=[WaitingForFileBlock], Event=[RequestFileBlock], New state=[WaitingForFileBlock]
I (227291) coreMQTT: De-serialized incoming PUBLISH packet: DeserializerResult=MQTTSuccess.
I (227291) coreMQTT: State record updated. New state=MQTTPublishDone.
I (227301) AWS_OTA: Received valid file block: Block index=320, Size=1776
I (227311) AWS_OTA: Received final block of the update.
I (227931) AWS_OTA: Signature verification succeeded.
I (227931) AWS_OTA: Received entire update and validated the signature.
I (228301) coreMQTT: Publishing message to $aws/things/GA913F0001/jobs/AFR_OTA-mSpaceGate_t0_2_5/update.

I (229541) coreMQTT: Ack packet deserialized with result: MQTTSuccess.
I (229541) coreMQTT: State record updated. New state=MQTTPublishDone.
I (229541) ota_over_mqtt: Sent PUBLISH packet to broker $aws/things/GA913F0001/jobs/AFR_OTA-mSpaceGate_t0_2_5/update to broker.

I (229551) ota_over_mqtt: Received OtaJobEventActivate callback from OTA Agent.
I (229541) coreMQTT: De-serialized incoming PUBLISH packet: DeserializerResult=MQTTSuccess.
I (229561) esp_image: segment 0: paddr=001f0020 vaddr=3f400020 size=3aecch (241356) map
I (229571) coreMQTT: State record updated. New state=MQTTPublishDone.
I (229591) ota_over_mqtt: Received update response: $aws/things/GA913F0001/jobs/AFR_OTA-mSpaceGate_t0_2_5/update/accepted{"timestamp":1709385169}af.
I (229651) esp_image: segment 1: paddr=0022aef4 vaddr=3ffbdb60 size=05124h ( 20772)
I (229671) esp_image: segment 2: paddr=00230020 vaddr=400d0020 size=e0210h (918032) map
I (229951) esp_image: segment 3: paddr=00310238 vaddr=3ffc2c84 size=00964h (  2404)
I (229951) esp_image: segment 4: paddr=00310ba4 vaddr=40080000 size=1fb24h (129828)
I (229991) esp_image: segment 0: paddr=001f0020 vaddr=3f400020 size=3aecch (241356) map
I (230071) esp_image: segment 1: paddr=0022aef4 vaddr=3ffbdb60 size=05124h ( 20772)
I (230081) esp_image: segment 2: paddr=00230020 vaddr=400d0020 size=e0210h (918032) map
I (230351) esp_image: segment 3: paddr=00310238 vaddr=3ffc2c84 size=00964h (  2404)
I (230361) esp_image: segment 4: paddr=00310ba4 vaddr=40080000 size=1fb24h (129828)
I (230961) wifi:state: run -> init (0)
I (230961) wifi:pm stop, total sleep time: 163061635 us / 227233436 us

I (230961) wifi:<ba-del>idx:0, tid:0
I (230961) wifi:new:<11,0>, old:<11,2>, ap:<255,255>, sta:<11,2>, prof:1
E (230971) wifi:NAN WiFi stop
I (230971) core_mqtt_agent_manager: WiFi disconnected.
I (230971) NETWORKING: Disconnected. Connecting to the AP again...
I (230981) NETWORKING: Disconnected. Connecting to the AP again...
I (231041) wifi:flush txq
I (231041) wifi:stop sw txq
I (231041) wifi:lmac stop hw txq
ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:7128
load:0x40078000,len:15692
ho 0 tail 12 room 4
load:0x40080400,len:4
0x40080400: _init at ??:?
load:0x40080404,len:3876
entry 0x4008064c
I (31) boot: ESP-IDF v5.1.2-684-g7cbee80fb9 2nd stage bootloader
I (31) boot: compile time Mar  2 2024 13:10:08
I (33) boot: Multicore bootloader
I (37) boot: chip revision: v3.1
I (40) boot.esp32: SPI Speed      : 40MHz
I (45) boot.esp32: SPI Mode       : DIO
I (50) boot.esp32: SPI Flash Size : 4MB
I (54) boot: Enabling RNG early entropy source...
I (60) boot: Partition Table:
I (63) boot: ## Label            Usage          Type ST Offset   Length
I (71) boot:  0 nvs              WiFi data        01 02 00010000 00006000
I (78) boot:  1 otadata          OTA data         01 00 00016000 00002000
I (85) boot:  2 phy_init         RF data          01 01 00018000 00001000
I (93) boot:  3 ota_0            OTA app          00 10 00020000 001c2000
I (100) boot:  4 ota_1            OTA app          00 11 001f0000 001c2000
I (108) boot:  5 storage          WiFi data        01 02 003b2000 00009000
I (115) boot:  6 settings         WiFi data        01 02 003bb000 00010000
I (123) boot: End of partition table
I (167) esp_image: segment 0: paddr=001f0020 vaddr=3f400020 size=3aecch (241356) map
I (255) esp_image: segment 1: paddr=0022aef4 vaddr=3ffbdb60 size=05124h ( 20772) load
I (263) esp_image: segment 2: paddr=00230020 vaddr=400d0020 size=e0210h (918032) map
I (595) esp_image: segment 3: paddr=00310238 vaddr=3ffc2c84 size=00964h (  2404) load
I (596) esp_image: segment 4: paddr=00310ba4 vaddr=40080000 size=1fb24h (129828) load
I (670) boot: Loaded app from partition at offset 0x1f0000
I (671) boot: Disabling RNG early entropy source...
I (682) cpu_start: Multicore app
I (683) cpu_start: Pro cpu up.
I (683) cpu_start: Starting app cpu, entry point is 0x400814c0
0x400814c0: call_start_cpu1 at C:/Espressif/v5.1/esp-idf/components/esp_system/port/cpu_start.c:159
I (672) cpu_start: App cpu up.
I (703) cpu_start: Pro cpu start user code
I (703) cpu_start: cpu freq: 160000000 Hz
I (703) cpu_start: Application information:
I (708) cpu_start: Project name:     mSpaceGate
I (713) cpu_start: App version:      t0.2.5
I (718) cpu_start: Compile time:     Mar  2 2024 14:04:43
I (724) cpu_start: ELF file SHA256:  3a93f59e049c6ac9...
I (730) cpu_start: ESP-IDF:          v5.1.2-684-g7cbee80fb9
I (736) cpu_start: Min chip rev:     v0.0
I (741) cpu_start: Max chip rev:     v3.99
I (745) cpu_start: Chip rev:         v3.1

Verification of new SW version no is ok and new SW is set for testing:
I (12473) AWS_OTA: In self test mode.
I (12483) AWS_OTA: New image has a higher version number than the current image: New image version=0.2.5, Previous image version=0.2.4
I (12493) AWS_OTA: Image version is valid: Begin testing file: File ID=0
I (12503) AWS_OTA: otaPal_SetPlatformImageState, 1
W (12503) AWS_OTA: Set image as testing!

During validation of new image other tasks are put on hold again:
I (16653) AWS_OTA: Job parsing success: OtaJobParseErr_t=OtaJobParseErrNone, Job name=AFR_OTA-mSpaceGate_t0_2_5
I (16663) coreMQTT: State record updated. New state=MQTTPublishDone.
I (16673) ota_over_mqtt: Received OtaJobEventReceivedJob callback from OTA Agent.
I (16683) ota_over_mqtt: Received update response: $aws/things/GA913F0001/jobs/AFR_OTA-mSpaceGate_t0_2_5/update/accepted{"timestamp":1709385188}0:c5:a8",
	"firmware":	"t0.2.5",
	"rssi":	-52
}t0_2_5","status":"IN_PROGRESS","statusDetails":{"self_test":"ready","updatedBy":"0x00020004"},"queuedAt":1709384957,"startedAt":1709384966,"lastUpdatedAt":1709385169,"versionNumber":15,"executionNumber":1,"jobDocument":{"afr_ota":{"protocols":["MQTT"],"streamname":"AFR_OTA-a5ccc605-4e35-4db8-a17f-ed918d372f7c","files":[{"filepath":"/","filesize":1312496,"fileid":0,"certfile":"Code Verify Key","sig-sha256-ecdsa":"MEUCIQDsSDL3R+0JJpIK0HfC/mrhfjg1NbLWwWpPmPKyCDlCKQIge2wNUqam3yhEO5pmO5C5IW7zX0AzhJkUxRQZ6D/qkkA="}]}}}}.
I (16693) report: OTA started. Preventing coreMQTT-Agent commands from being enqueued.
I (16693) AWS_OTA: otaPal_GetPlatformImageState
I (16763) sub_pub_unsub: OTA started. Preventing coreMQTT-Agent commands from being enqueued.
I (16773) esp_ota_ops: aws_esp_ota_get_boot_flags: 1
I (16773) core_mqtt_agent_manager: OTA started.
I (16783) esp_ota_ops: [1] aflags/seq:0x1/0x2, pflags/seq:0x2/0x1
I (16793) ota_over_mqtt: OTA Event processing completed. Freeing the event buffer to pool.
I (16803) AWS_OTA: Current State=[CreatingFile], Event=[ReceivedJobDocument], New state=[CreatingFile]
I (16813) AWS_OTA: Beginning self-test.
I (16823) AWS_OTA: otaPal_GetPlatformImageState
I (16823) esp_ota_ops: aws_esp_ota_get_boot_flags: 1
I (16833) esp_ota_ops: [1] aflags/seq:0x1/0x2, pflags/seq:0x2/0x1
I (16833) ota_over_mqtt: Received OtaJobEventStartTest callback from OTA Agent.
I (16843) AWS_OTA: otaPal_SetPlatformImageState, 2
I (16853) AWS_OTA: Set image as valid one!

OTA Job is completed, but other tasks never receive flag CORE_MQTT_AGENT_OTA_STOPPED_EVENT and remain on hold. They only can be recovered by reboot / restart the device
I (21063) ota_over_mqtt: New image validation succeeded in self test mode.
I (21073) coreMQTT: State record updated. New state=MQTTPublishDone.
I (21073) AWS_OTA: Current State=[WaitingForJob], Event=[StartSelfTest], New state=[WaitingForJob]
I (21083) ota_over_mqtt: Received update response: $aws/things/GA913F0001/jobs/AFR_OTA-mSpaceGate_t0_2_5/update/accepted{"timestamp":1709385192}0:c5:a8",
	"firmware":	"t0.2.5",
	"rssi":	-52
}t0_2_5","status":"IN_PROGRESS","statusDetails":{"self_test":"ready","updatedBy":"0x00020004"},"queuedAt":1709384957,"startedAt":1709384966,"lastUpdatedAt":1709385169,"versionNumber":15,"executionNumber":1,"jobDocument":{"afr_ota":{"protocols":["MQTT"],"streamname":"AFR_OTA-a5ccc605-4e35-4db8-a17f-ed918d372f7c","files":[{"filepath":"/","filesize":1312496,"fileid":0,"certfile":"Code Verify Key","sig-sha256-ecdsa":"MEUCIQDsSDL3R+0JJpIK0HfC/mrhfjg1NbLWwWpPmPKyCDlCKQIge2wNUqam3yhEO5pmO5C5IW7zX0AzhJkUxRQZ6D/qkkA="}]}}}}.
I (23153) coreMQTT: De-serialized incoming PUBLISH packet: DeserializerResult=MQTTSuccess.
I (23153) coreMQTT: State record updated. New state=MQTTPubAckSend.
I (23153) ota_over_mqtt: Received job message callback, size 24.

I (23163) AWS_OTA: No active job available in received job document: OtaJobParseErr_t=OtaJobParseErrNoActiveJobs
I (23173) ota_over_mqtt: Received OtaJobEventNoActiveJob callback from OTA Agent.
I (23183) AWS_OTA: otaPal_GetPlatformImageState
I (23183) esp_ota_ops: aws_esp_ota_get_boot_flags: 1
I (23193) esp_ota_ops: [1] aflags/seq:0x2/0x2, pflags/seq:0x2/0x1
I (23203) ota_over_mqtt: OTA Event processing completed. Freeing the event buffer to pool.
I (23213) AWS_OTA: Current State=[WaitingForJob], Event=[ReceivedJobDocument], New state=[CreatingFile]
I (31943) ota_over_mqtt: OTA agent suspend by timer.
W (32943) AWS_OTA: OTA Timer handle NULL for Timerid=0, can't stop.
I (32943) AWS_OTA: OTA Agent is suspended.
I (32943) AWS_OTA: Current State=[Suspended], Event=[Suspend], New state=[Suspended]
I (152943) ota_over_mqtt: OTA agent resumed by timer.
I (153943) AWS_OTA: otaPal_GetPlatformImageState
I (153943) esp_ota_ops: aws_esp_ota_get_boot_flags: 1
I (153943) esp_ota_ops: [1] aflags/seq:0x2/0x2, pflags/seq:0x2/0x1
I (153943) AWS_OTA: Current State=[RequestingJob], Event=[Resume], New state=[RequestingJob]
I (154393) ota_over_mqtt: Subscribed to topic $aws/things/GA913F0001/jobs/notify-next.

I (154393) AWS_OTA: Subscribed to MQTT topic: $aws/things/GA913F0001/jobs/notify-next
I (155393) coreMQTT: Publishing message to $aws/things/GA913F0001/jobs/$next/get.

I (156603) coreMQTT: Ack packet deserialized with result: MQTTSuccess.
I (156603) coreMQTT: State record updated. New state=MQTTPublishDone.
I (156603) ota_over_mqtt: Sent PUBLISH packet to broker $aws/things/GA913F0001/jobs/$next/get to broker.

I (156603) coreMQTT: De-serialized incoming PUBLISH packet: DeserializerResult=MQTTSuccess.
I (156613) AWS_OTA: Current State=[WaitingForJob], Event=[RequestJobDocument], New state=[WaitingForJob]
I (156623) coreMQTT: State record updated. New state=MQTTPublishDone.
I (156643) ota_over_mqtt: Received job message callback, size 53.

I (156653) AWS_OTA: No active job available in received job document: OtaJobParseErr_t=OtaJobParseErrNoActiveJobs
I (156663) ota_over_mqtt: Received OtaJobEventNoActiveJob callback from OTA Agent.
I (156663) AWS_OTA: otaPal_GetPlatformImageState
I (156673) esp_ota_ops: aws_esp_ota_get_boot_flags: 1
I (156683) esp_ota_ops: [1] aflags/seq:0x2/0x2, pflags/seq:0x2/0x1
I (156683) ota_over_mqtt: OTA Event processing completed. Freeing the event buffer to pool.
I (156693) AWS_OTA: Current State=[WaitingForJob], Event=[ReceivedJobDocument], New state=[CreatingFile]

Sorry for big number of logs, but I tried to explain as detailed as I can.

I've tried to update the prvOtaAppCallback function to the following state, by adding case OtaJobEventUpdateComplete:
static void prvOtaAppCallback(OtaJobEvent_t event, void *pData) {
  OtaErr_t err = OtaErrUninitialized;

  switch (event) {
  case OtaJobEventActivate:
    ESP_LOGI(TAG, "Received OtaJobEventActivate callback from OTA Agent.");

    /**
     * Activate the new firmware image immediately. Applications can choose to
     * postpone the activation to a later stage if needed.
     */
    err = OTA_ActivateNewImage();

    /**
     * Activation of the new image failed. This indicates an error that requires
     * a follow up through manual activation by resetting the device. The demo
     * reports the error and shuts down the OTA agent.
     */
    ESP_LOGE(TAG, "New image activation failed.");

    /* Shutdown OTA Agent, if it is required that the unsubscribe operations are
     * not performed while shutting down please set the second parameter to 0
     * instead of 1. */
    OTA_Shutdown(0, 1);

    break;

  case OtaJobEventFail:
    ESP_LOGI(TAG, "Received an OtaJobEventFail notification from OTA Agent.");

    /* Signal coreMQTT-Agent network manager that an OTA job has stopped. */
    xCoreMqttAgentManagerPost(CORE_MQTT_AGENT_OTA_STOPPED_EVENT);
    break;

  case OtaJobEventStartTest:

    /* This demo just accepts the image since it was a good OTA update and
     * networking and services are all working (or we would not have made it
     * this far). If this were some custom device that wants to test other
     * things before validating new image, this would be the place to kick off
     * those tests before calling OTA_SetImageState() with the final result of
     * either accepted or rejected. */

    ESP_LOGI(TAG, "Received OtaJobEventStartTest callback from OTA Agent.");

    err = OTA_SetImageState(OtaImageStateAccepted);

    if (err == OtaErrNone) {
      ESP_LOGI(TAG, "New image validation succeeded in self test mode.");
    } else {
      ESP_LOGE(TAG, "Failed to set image state as accepted with error %d.",
               err);
    }

    break;

  case OtaJobEventProcessed:

    ESP_LOGI(
        TAG,
        "OTA Event processing completed. Freeing the event buffer to pool.");
    configASSERT(pData != NULL);
    prvOTAEventBufferFree((OtaEventData_t *)pData);

    break;

  case OtaJobEventSelfTestFailed:
    ESP_LOGI(TAG,
             "Received OtaJobEventSelfTestFailed callback from OTA Agent.");

    /* Requires manual activation of previous image as self-test for
     * new image downloaded failed.*/
    ESP_LOGE(TAG,
             "OTA Self-test failed for new image. shutting down OTA Agent.");

    /* Shutdown OTA Agent, if it is required that the unsubscribe operations are
     * not performed while shutting down please set the second parameter to 0
     * instead of 1. */
    OTA_Shutdown(0, 1);

    /* Signal coreMQTT-Agent network manager that an OTA job has stopped. */
    xCoreMqttAgentManagerPost(CORE_MQTT_AGENT_OTA_STOPPED_EVENT);
    break;

  case OtaJobEventReceivedJob:
    ESP_LOGI(TAG, "Received OtaJobEventReceivedJob callback from OTA Agent.");
    /* Signal coreMQTT-Agent network manager that an OTA job has started. */
    xCoreMqttAgentManagerPost(CORE_MQTT_AGENT_OTA_STARTED_EVENT);
    break;

  case OtaJobEventUpdateComplete:
    ESP_LOGI(TAG,
             "Received OtaJobEventUpdateComplete callback from OTA Agent.");
    /* Signal coreMQTT-Agent network manager that an OTA job has stopped. */
    xCoreMqttAgentManagerPost(CORE_MQTT_AGENT_OTA_STOPPED_EVENT);
    break;

  case OtaJobEventNoActiveJob:
    ESP_LOGI(TAG, "Received OtaJobEventNoActiveJob callback from OTA Agent.");
    /* No more jobs available in IoTCore, no further actions on this event. */
    break;

  default:
    ESP_LOGW(TAG,
             "Received an unhandled callback event from OTA Agent, "
             "event = %d",
             event);

    break;
  }
}

but there is the same behaviour
log.mSpaceGate.20240302153506.txt
The solution which works for me is to add the CORE_MQTT_AGENT_OTA_STOPPED_EVENT to OtaJobEventStartTest after check if OTA_SetImageState
static void prvOtaAppCallback(OtaJobEvent_t event, void *pData) {
  OtaErr_t err = OtaErrUninitialized;

  switch (event) {
  case OtaJobEventActivate:
    ESP_LOGI(TAG, "Received OtaJobEventActivate callback from OTA Agent.");

    /**
     * Activate the new firmware image immediately. Applications can choose to
     * postpone the activation to a later stage if needed.
     */
    err = OTA_ActivateNewImage();

    /**
     * Activation of the new image failed. This indicates an error that requires
     * a follow up through manual activation by resetting the device. The demo
     * reports the error and shuts down the OTA agent.
     */
    ESP_LOGE(TAG, "New image activation failed.");

    /* Shutdown OTA Agent, if it is required that the unsubscribe operations are
     * not performed while shutting down please set the second parameter to 0
     * instead of 1. */
    OTA_Shutdown(0, 1);

    break;

  case OtaJobEventFail:
    ESP_LOGI(TAG, "Received an OtaJobEventFail notification from OTA Agent.");

    /* Signal coreMQTT-Agent network manager that an OTA job has stopped. */
    xCoreMqttAgentManagerPost(CORE_MQTT_AGENT_OTA_STOPPED_EVENT);
    break;

  case OtaJobEventStartTest:

    /* This demo just accepts the image since it was a good OTA update and
     * networking and services are all working (or we would not have made it
     * this far). If this were some custom device that wants to test other
     * things before validating new image, this would be the place to kick off
     * those tests before calling OTA_SetImageState() with the final result of
     * either accepted or rejected. */

    ESP_LOGI(TAG, "Received OtaJobEventStartTest callback from OTA Agent.");

    err = OTA_SetImageState(OtaImageStateAccepted);

    if (err == OtaErrNone) {
      ESP_LOGI(TAG, "New image validation succeeded in self test mode.");
    } else {
      ESP_LOGE(TAG, "Failed to set image state as accepted with error %d.",
               err);
    }
    xCoreMqttAgentManagerPost(CORE_MQTT_AGENT_OTA_STOPPED_EVENT);
    break;

  case OtaJobEventProcessed:

    ESP_LOGI(
        TAG,
        "OTA Event processing completed. Freeing the event buffer to pool.");
    configASSERT(pData != NULL);
    prvOTAEventBufferFree((OtaEventData_t *)pData);

    break;

  case OtaJobEventSelfTestFailed:
    ESP_LOGI(TAG,
             "Received OtaJobEventSelfTestFailed callback from OTA Agent.");

    /* Requires manual activation of previous image as self-test for
     * new image downloaded failed.*/
    ESP_LOGE(TAG,
             "OTA Self-test failed for new image. shutting down OTA Agent.");

    /* Shutdown OTA Agent, if it is required that the unsubscribe operations are
     * not performed while shutting down please set the second parameter to 0
     * instead of 1. */
    OTA_Shutdown(0, 1);

    /* Signal coreMQTT-Agent network manager that an OTA job has stopped. */
    xCoreMqttAgentManagerPost(CORE_MQTT_AGENT_OTA_STOPPED_EVENT);
    break;

  case OtaJobEventReceivedJob:
    ESP_LOGI(TAG, "Received OtaJobEventReceivedJob callback from OTA Agent.");
    /* Signal coreMQTT-Agent network manager that an OTA job has started. */
    xCoreMqttAgentManagerPost(CORE_MQTT_AGENT_OTA_STARTED_EVENT);
    break;

  case OtaJobEventNoActiveJob:
    ESP_LOGI(TAG, "Received OtaJobEventNoActiveJob callback from OTA Agent.");
    /* No more jobs available in IoTCore, no further actions on this event. */
    break;

  default:
    ESP_LOGW(TAG,
             "Received an unhandled callback event from OTA Agent, "
             "event = %d",
             event);

    break;
  }
}

LOG:
log.mSpaceGate.20240302161840.txt
with this function definition both task are start working again after OTA completed:
I (21180) ota_over_mqtt: New image validation succeeded in self test mode.
I (21190) coreMQTT: State record updated. New state=MQTTPublishDone.
I (21190) report: OTA stopped. No longer preventing coreMQTT-Agent commands from being enqueued.
I (21190) AWS_OTA: Current State=[WaitingForJob], Event=[StartSelfTest], New state=[WaitingForJob]
I (21210) sub_pub_unsub: OTA stopped. No longer preventing coreMQTT-Agent commands from being enqueued.
I (21200) ota_over_mqtt: Received update response: $aws/things/GA913F0001/jobs/AFR_OTA-mSpaceLock-t0_2_7/update/accepted{"timestamp":1709393030}0:c5:a8",
	"firmware":	"t0.2.7",
	"rssi":	-56
}t0_2_7","status":"IN_PROGRESS","statusDetails":{"self_test":"ready","updatedBy":"0x00020006"},"queuedAt":1709392696,"startedAt":1709392802,"lastUpdatedAt":1709393006,"versionNumber":15,"executionNumber":1,"jobDocument":{"afr_ota":{"protocols":["MQTT"],"streamname":"AFR_OTA-508f39ed-54b2-44e9-bb2d-37c3a845ab0f","files":[{"filepath":"/","filesize":1312512,"fileid":0,"certfile":"Code Verify Key","sig-sha256-ecdsa":"MEQCIBkZyQTR8ho/2aZAoLz07TGXPEbKzjneoCg+yCeXBjiUAiAsoCRg4Fd6bIk5cC+h9YmLEDylKOo1jHGsaRfu9pKU7g=="}]}}}}.
I (21230) core_mqtt_agent_manager: OTA stopped.
I (21780) coreMQTT: De-serialized incoming PUBLISH packet: DeserializerResult=MQTTSuccess.
I (21780) coreMQTT: State record updated. New state=MQTTPubAckSend.
I (21780) ota_over_mqtt: Received job message callback, size 24.

I (21790) AWS_OTA: No active job available in received job document: OtaJobParseErr_t=OtaJobParseErrNoActiveJobs
I (21800) ota_over_mqtt: Received OtaJobEventNoActiveJob callback from OTA Agent.
I (21810) AWS_OTA: otaPal_GetPlatformImageState
I (21810) esp_ota_ops: aws_esp_ota_get_boot_flags: 1
I (21820) esp_ota_ops: [1] aflags/seq:0x2/0x4, pflags/seq:0x2/0x3
I (21820) ota_over_mqtt: OTA Event processing completed. Freeing the event buffer to pool.
I (21830) AWS_OTA: Current State=[WaitingForJob], Event=[ReceivedJobDocument], New state=[CreatingFile]
I (24740) sub_pub_unsub: Task "SubPub0" sending subscribe request to coreMQTT-Agent for topic filter: /filter/SubPub0 with id 4
I (25050) sub_pub_unsub: Subscribe 4 for topic filter /filter/SubPub0 succeeded for task "SubPub0".
I (25050) sub_pub_unsub: Task "SubPub0" sending publish request to coreMQTT-Agent with message "SubPub0" on topic "/filter/SubPub0" with ID 5.
I (25070) sub_pub_unsub: Task "SubPub0" waiting for publish 5 to complete.
I (26050) coreMQTT: Publishing message to /filter/SubPub0.

I will prepare pull request with that change proposal.

My fix was this. Not sure if this lines up with the desired flow...
switch( event )
    {
        case OtaJobEventActivate:
            ESP_LOGI( TAG, "Received OtaJobEventActivate callback from OTA Agent." );

            /**
             * OTA Successful. Report Success to JOBS portal. X Monkey X
            */
            OTA_SetImageState( OtaImageStateAccepted );

            /**
             * Activate the new firmware image immediately. Applications can choose to postpone
             * the activation to a later stage if needed.
             */
            err = OTA_ActivateNewImage();

Hi,
Glad to see PR has merged and solved the issue here.
Just share my opinion about additional question:

Additional question
In case OtaJobEventSelfTestFailed OTA_Shutdown is executed, should program also trigger xCoreMqttAgentManagerPost(CORE_MQTT_AGENT_OTA_STOPPED_EVENT); in that case or ot will be covered by
OtaJobEventFail any way?

It seems appropriate to trigger xCoreMqttAgentManagerPost(CORE_MQTT_AGENT_OTA_STOPPED_EVENT) again at this point to resume other tasks. However, if the OTA is shut down here, the entire OTA service would be disabled after this. The reference code provided is intended to demonstrate the ability to run OTA with the simplest error handling approach. I will test it with xCoreMqttAgentManagerPost(CORE_MQTT_AGENT_OTA_STOPPED_EVENT) added and consider raising a PR for the same.
Appreciate the contributions from all of you.

Closing as PRs are merged. Thanks for your contributions!


Save Issues

I have a brew, of which I have imputed new content multiple times, but it rarely saves the changes made, reverting to the old version. I don't know why it does this, but i'd like it to be addressed.
Additional Details
Share Link :
or
Brew code to reproduce : Click to expand
PASTE BREW CODE HERE

By chance, do you have the brew open in  another browser window/tab when this happens?

I have my profile with all my brews open, but no duplicates
On Sat, Dec 2, 2017 at 12:34 PM, Sansd20<EMAIL_ADDRESS>wrote:

By chance, do you have the brew open in another browser window/tab when
this happens?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/stolksdorf/homebrewery/issues/563#issuecomment-348725103,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AamgMzu1nwGNcWf-pHFzycUW3npB38jYks5s8dBwgaJpZM4QzW2T
.

Duplicate of #654


My editor crashed

Steps to Reproduce
When I try to setup my debug and enable some debugging line, my idea has crashed with errors
Logs
exception
VersionCheckError: VersionCheckError: Command exited with code 69: git log -n 1 --pretty=format:%ad --date=iso
Standard error:
Agreeing to the Xcode/iOS license requires admin privileges, please run “sudo xcodebuild -license” and then retry this command.
Flutter Doctor
Paste the output of running flutter doctor here.

For more information about diagnosing and reporting Flutter bugs, please see https://flutter.io/bug-reports/.

It shows some licensing requirement. After agreeing to the license of Xcode, the debug problem is resolved. But I have no idea why I got this error when I worked with Android Emulator.

I think this issue is stale and non-actionable. Please reopen if you experience the crash again.


Added devfile for Stonesoup Onboarding

@jsenko @riprasad Please review and merge.

@riprasad Can you please double-check?

LGTM. Thank you @NikishaPatil
Merging.


"Serializing a plain Exception object, such as the following..." - nothing follows

The final bullet point of "Differences in serializers" reads:
> - Serializing a plain Exception object, such as the following, doesn't work well with DataContractSerializer and DataContractJsonSerializer:
However, the next section begins immediately and is entirely unrelated. What are the exceptions we can't serialize with these serializers?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: bbf5fdf4-e2bc-8719-8163-1f6cfbab6d44
Version Independent ID: baef07a5-5fb9-3059-4782-0356d65ebb3a
Content: Migrating Your Windows Store App to .NET Native
Content Source: docs/framework/net-native/migrating-your-windows-store-app-to-net-native.md
Product: dotnet-framework
GitHub Login: @rpetrusha
Microsoft Alias: ronpet

@Compynerd255 Looking through the history of that file, I can't find anything that would indicate something was there. Perhaps it should just be reworded.
@rpetrusha Do you remember anything about this? Perhaps we should just remove that "such as the following" clause and fix the punctuation at the end of the sentence?

It looks like there was some bad code reference inherited from MSDN days. This is what it used to look like:

Probably Ron would know best what existed here before.

Yes, I do remember a few of the details. The original code was somehow lost, possibly during one of our migrations, but more likely because of content loss in Parsnip. Some time later, when I realized that the code was missing, I couldn't find a local version to replace it.
I'll remove the mention  of an example.

The text "such as the following" is still there.

@Compynerd255 I see the change in the PR, but not the live site. So it may just be a delay in publishing.


Added ability to require a loaded session

1. Requiring a session context to be loaded
With the previous mobx replacement I added the ability for any component to wrap itself with withSession that will inject the session context (similar to mobx inject):
@withSession
class MyComponent extends React.Component {

   render() {
     const { user } = this.context;
     // ... do some stuff with user
   }
}

This will inject the session context and re-render when the user changes, however the user is initially null while the app is fetching /users/me. First of all, note that this is a GOOD thing because it allows components to decide for themselves what can be rendered with/without the user and we can serve a more responsive app instead of just a blank shell while the app is bootstrapping (context.loading will give you the loading state).
 This is meant to alleviate that by exporting another wrapper withLoadedSession that will not mount until the app is bootstrapped:
@withLoadedSession
class MyComponent extends React.Component {

   componentDidMount() {
     const { user } = this.context;  // Guaranteed to exist if logged in
   }
}

2. Reacting for changes to the session
As a companion to the above, sometimes you need to need to know when session data has changed and be able to react to it. I'm leveraging React getSnapshotBeforeUpdate to expose the last session in componentDidUpdate in the same way as lastProps and lastState. This will apply to both withSession and withLoadedSession above. Example:

@withLoadedSession
class MyComponent extends React.Component {

   componentDidUpdate(lastProps, lastState, lastContext) {
     const { user } = this.context;
     // This will be run when the user signs in/out
     if (user !== lastContext.user) {
       if (user) {
         ThirdPartyApp.updateUserInfo(user);
       } else {
         ThirdPartyApp.removeUser();
       }
     }
   }

   componentDidMount() {
     const { user } = this.context;
     ThirdPartyApp.initializeUser(user);
   }
}

I feel you on that. It seems there's a general incompatibility with hooks and the context API such that we're still going to need this for now.

Actually just researched this and it looks like we can support both class components and hooks IF we rewrite the session provider as a hook.
I want to do this because supporting both is more important to me than my EXTREME DISTASTE FOR HOOKS :)
Let's do this in a new PR though ... I also want to get @dominiek input on this and make sure he's aware of it before I merge

OK updated with tests for session.js as well as a README.md in stores.
Also added support for injecting the session with hooks.

LGTM


Implemented DSU in C++

This code contains implementation of DSU and how DSU can be used to find cycles in a graph.

hacktoberfest-accepted


Update envoy metrics service and access log service config

This PR migrates to the newer flags for the envoy metrics service and access log service config that support setting up the TLS context and keepalive config.

Hi @joeyb. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/ok-to-test
Thanks!

@joeyb: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gencheck_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test gencheck_installer

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@joeyb: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gencheck_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test gencheck_installer

build_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test build_installer

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@joeyb: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gencheck_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test gencheck_installer

build_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test build_installer

lint_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test lint_installer

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@joeyb: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gencheck_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test gencheck_installer

build_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test build_installer

lint_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test lint_installer

noauth_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test noauth_installer

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@joeyb: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gencheck_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test gencheck_installer

build_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test build_installer

lint_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test lint_installer

noauth_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test noauth_installer

base_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test base_installer

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@joeyb: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gencheck_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test gencheck_installer

build_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test build_installer

lint_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test lint_installer

noauth_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test noauth_installer

base_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test base_installer

demo_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test demo_installer

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@joeyb: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

noauth_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test noauth_installer

base_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test base_installer

demo_installer
3e077b03c8d30ba21ef7caf375ede9b45d1adb60
link
/test demo_installer

gencheck_installer
3c2b5232a1826f7887f3e0f7ac20a5f8529f2e39
link
/test gencheck_installer

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Ability to add graphs

It would be nice to be able add graphs to our markdown file.
You could use the charter library that marker uses.

chart.js would probably be a better choice, now that I think of it


Standarize E2E test asserts and increase wait time

Converts the templating asserts to use the shared infrastructure asserts.
Increases the timeout for templating tests from 10 seconds to 30 to help with reliability.

This was giving me grief today in several of my PRs. Seems that since we've moved to BYOC queues these tests have become unstable again. I've increased the timeout to see if that helps and replaced the asserts for the ones that we use in Blazor which are more robust.


Architecture refactor Overall Done

With this PR I created and implemented the described files architecture on the issue #113.
This PR is kind of a long one, so please read the git commits to save time and walk trough the changes more easily.
Please refer to the code to know more about it, and let me know if something is wrong.
Hope that is clear.
Massiles.

This looks great to me- Thank you for refactoring the architecture! It definitely needed help.

Thanks for the great feedback. I appreciate it.
Massiles


Remove GS JUG from 2024 MP shirts

And update print files and mockups

The files have been update and added to the drive: @aeiras

https://drive.google.com/drive/folders/1VuGDwQ_NNdU5nwQV-3a-sDfLhOfLAzid?usp=drive_link

Thank you, @rstjames!

@emecas,
Please connect with @jclingan to initiate the 7-day business vote ASAP. Questions, shoot and thanks for owning this effort.

02/29/2024 - Followed in [microprofile-steering]  to defined what else is required start voting ASAP  CC: @jclingan

@emecas @aeiras should be removed, too?

Thanks @rstjames , by following the recent communication from EF, I would think so:
_On Feb 28, 2024, at 12:42 PM<EMAIL_ADDRESS>wrote:
All:
Please note Hunan AsiaInfo Anhui Technology Limited no longer holds membership with the MicroProfile Working Group.  As a result, their logo needs to be removed from https://microprofile.io/workinggroup/.
Also, I'd like to draw your attention that the Garden State Java User Group logo appears to be missing.  While they are currently a Guest member, they should be included in the member's list on the website._
Also, following the replies about the plan on extending to Garden State Java User Group an invitation by the Steering Committee as a guest member. Would not have more sense keeping their logo?

Updated shirt: I added to the drive as "10 members" drive. Ten logos are a bit trickier @aeiras @emecas
https://drive.google.com/drive/folders/1VuGDwQ_NNdU5nwQV-3a-sDfLhOfLAzid?usp=drive_link

@rstjames  this version looks good.
It will add Garden State formally after the JUG is voted as a guest. I will file a ticket for changes to MPWG members to connect the latest updates.
Thank you.

As discussed today, the latest changes look good, @rstjames!
@emecas, this is a go after today's call review-- the ballot template is ready for your review and usage. :)

@emecas, this is a go after today's call review-- the ballot template is ready for your review and usage. :)

thanks @aeiras ,  where is it ?

@emecas, this is a go after today's call review-- the ballot template is ready for your review and usage. :)

thanks @aeiras , where is it ?

answering to myself https://github.com/eclipse/microprofile-marketing/issues/840#issuecomment-1977652831 :)

Good updates everyone. closing this one. :)


Casting issue on the stat_badge.dart

Explicit casting is required at the beginning of the valueChanged() function.
T change = widget.statValue.number - _lastStatValue as T;

THE SAME

the same

Same issue here.


Google DNS fallback logic does not work when only dnssearch is set

Description
If your host is using <IP_ADDRESS> for the DNS nameserver Docker uses Google DNS for the containers (<IP_ADDRESS>, <IP_ADDRESS>) instead of <IP_ADDRESS>.  This fallback behavior does not work if --dns-search is set.

Steps to reproduce the issue:

Run docker run --dns-search foo.com ubuntu cat /etc/resolv.conf

Describe the results you received:
search foo.com
nameserver <IP_ADDRESS>

Describe the results you expected:
search foo.com
nameserver <IP_ADDRESS>
nameserver <IP_ADDRESS>

Additional information you deem important (e.g. issue happens only occasionally):
Output of docker version:
Client:
 Version:      1.12.5
 API version:  1.24
 Go version:   go1.6.4
 Git commit:   7392c3b
 Built:        Fri Dec 16 02:42:17 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.5
 API version:  1.24
 Go version:   go1.6.4
 Git commit:   7392c3b
 Built:        Fri Dec 16 02:42:17 2016
 OS/Arch:      linux/amd64

Output of docker info:
Containers: 15
 Running: 11
 Paused: 0
 Stopped: 4
Images: 10
Server Version: 1.12.5
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 86
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null host bridge overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor seccomp
Kernel Version: 4.4.0-31-generic
Operating System: Ubuntu 16.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 975 MiB
Name: ubuntu
ID: OOSO:YJMC:LA6W:TWZL:XZK2:BMNH:OVL5:DQBE:ZJMF:KD4C:VVC5:7MDH
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
 <IP_ADDRESS>/8

Additional environment details (AWS, VirtualBox, physical, etc.):

I think the issue is located here:
https://github.com/docker/docker/blob/v1.13.0-rc4/vendor/github.com/docker/libnetwork/sandbox_dns_unix.go#L191-L220
In case --dns-search is provided and --dns is not provided, resolvconf.FilterResolvDNS() will not be invoked to replace localhost/127.*.
I think the following diff may resolve the issue?
diff --git a/vendor/github.com/docker/libnetwork/sandbox_dns_unix.go b/vendor/github.com/docker/libnetwork/sandbox_dns_unix.go
index f4d1fad..0ee398f 100644
--- a/vendor/github.com/docker/libnetwork/sandbox_dns_unix.go
+++ b/vendor/github.com/docker/libnetwork/sandbox_dns_unix.go
@@ -208,7 +208,9 @@ func (sb *sandbox) setupDNS() error {
                if err != nil {
                        return err
                }
-       } else {
+               currRC = newRC
+       }
+       if len(sb.config.dnsList) == 0 {
                // Replace any localhost/127.* (at this point we have no info about ipv6, pass it as true)
                if newRC, err = resolvconf.FilterResolvDNS(currRC.Content, true); err != nil {
                        return err

@yongtang The block you referred to is where the issue is. But the fix needs to be more than calling resolvconf.FilterResolvDNS(). If any one of the dns configs --dns, --dns-opt, --dns-search is passed the code currently uses all the three from the user config to build the resolv.conf. Fix would be to use only the user provided config and take the rest from the host resolv.conf. Please push a libnetwork PR if you want to fix this.

Fix would be to use only the user provided config and take the rest from the host resolv.conf.

I guess we need some documentation around that as well, as the search-domain may be tied to the DNS server that's used, and which, in this example, is ignored/replaced by <IP_ADDRESS>

Added a PR https://github.com/docker/libnetwork/pull/1606 in libnetwork. Please take a look.


Missing custom error for require_params?

I just noticed that even though there's a fairly robust set of EndState::Error subclasses, it looks like the error raised when require_params are missing is just the basic RuntimeError. This makes it very difficult to specify a rescue clause that only fires when require_params fails.
As I was mapping out the changes that an EndState::MissingParams subclass would need, it also occurred to me that require_params should work like a Guard, in the same way persistence_on works like a Concluder. And that the MissingParams error should only be raised during a hard transition.
Thoughts?

I think that makes a lot of sense. I also like the consistency of it being a guard. If it becomes a guard though, it seems that if it fails it would either be false or with a hard transition is would raise GuardFailed. So we still wouldn't have an error specific to missing params. Maybe that's ok.
I think I'm good wither either solution. Either it turns into a built in guard and acts like any other guard (and it should be the first guard) or it stays how it is but on failure it tosses a new MissingParams error instead of a more generic one.
Feel free to submit a PR with the one you like best.

Cool. I think my plan is to go with the added error class, at least for a first pass. While I still think a form of Guard will eventually be the more correct solution, I also think there are several unknowns that I'm not sure I have the time to devote to, just now...

This was address in #34 and included in v1.1.0