"TypeError: Cannot read property 'forEach'

Hi,
Getting below error when calling workflow having http task. I have defined below in the input parameter as below.
"inputParameters": {
"http_request": {
"uri": "http://localhost:8880/apis/testNames",
"method": "GET",
"accept": "application/json;charset=UTF-8"
}
}
500 - Internal Server Error
"TypeError: Cannot read property 'forEach' of undefined    at _callee2$ (/Users/ajay/OfficeWork/Office_Code/ECMS_Conductor/conductor/ui/dist/webpack:/src/api/wfe.js:49:5)    at tryCatch (/Users/ajay/OfficeWork/Office_Code/ECMS_Conductor/conductor/ui/node_modules/regenerator-runtime/runtime.js:64:40)    at GeneratorFunctionPrototype.invoke [as _invoke] (/Users/ajay/OfficeWork/Office_Code/ECMS_Conductor/conductor/ui/node_modules/regenerator-runtime/runtime.js:355:22)    at GeneratorFunctionPrototype.prototype.(anonymous function) [as next] (/Users/ajay/OfficeWork/Office_Code/ECMS_Conductor/conductor/ui/node_modules/regenerator-runtime/runtime.js:116:21)    at tryCatch (/Users/ajay/OfficeWork/Office_Code/ECMS_Conductor/conductor/ui/node_modules/regenerator-runtime/runtime.js:64:40)    at GeneratorFunctionPrototype.invoke [as _invoke] (/Users/ajay/OfficeWork/Office_Code/ECMS_Conductor/conductor/ui/node_modules/regenerator-runtime/runtime.js:297:24)    at GeneratorFunctionPrototype.prototype.(anonymous function) [as next] (/Users/ajay/OfficeWork/Office_Code/ECMS_Conductor/conductor/ui/node_modules/regenerator-runtime/runtime.js:116:21)    at step (/Users/ajay/OfficeWork/Office_Code/ECMS_Conductor/conductor/ui/dist/server.js:8603:192)    at /Users/ajay/OfficeWork/Office_Code/ECMS_Conductor/conductor/ui/dist/server.js:8603:362    at run (/Users/ajay/OfficeWork/Office_Code/ECMS_Conductor/conductor/ui/node_modules/core-js/modules/es6.promise.js:87:22)\n"
Please suggest

Dont know the purpose but i have fixed the issue locally and its working.
Please let me know if its a valid issue.
For me it was showing "schemaVersion": 0, and as per logic it was using getTaskInputV1(...).
I have used getTaskInputV2() and its working after that.

Closing for now - we will add a validation to ensure the schemaVersion is set to a valid value.


[Fix][Connector-V2] Fix starrocks Content-Length header already present error

Purpose of this pull request
This PR fix stream load error when use starrocks sink. Please refer https://forum.mirrorship.cn/t/topic/496 and same error on doris #4277

Does this PR introduce any user-facing change?
no

How was this patch tested?
hard to add test case. Unable to reproduce stably

Check list

[ ] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[ ] If necessary, please update the documentation to describe the new feature. https://github.com/apache/seatunnel/tree/dev/docs
[ ] If you are contributing the connector code, please check that the following files are updated:

Update change log that in connector document. For more details you can refer to connector-v2
Update plugin-mapping.properties and add new connector information in it
Update the pom file of seatunnel-dist

[ ] Update the release-note.

cc @hailin0 @EricJoy2048


Doesn't build with rust 1.50.0

I get
error[E0658]: const generics are unstable
   --> /Users/jrmuizel/.cargo/registry/src/github.com-1ecc6299db9ec823/rkyv-0.6.4/src/core_impl/mod.rs:406:35
    |
406 | unsafe impl<T: ArchiveCopy, const N: usize> ArchiveCopy for [T; N] {}
    |                                   ^
    |
    = note: see issue #74878 <https://github.com/rust-lang/rust/issues/74878> for more information

error[E0658]: const generics are unstable
   --> /Users/jrmuizel/.cargo/registry/src/github.com-1ecc6299db9ec823/rkyv-0.6.4/src/core_impl/mod.rs:409:24
    |
409 | impl<T: Archive, const N: usize> Archive for [T; N] {
    |                        ^
    |
    = note: see issue #74878 <https://github.com/rust-lang/rust/issues/74878> for more information

error[E0658]: const generics are unstable
   --> /Users/jrmuizel/.cargo/registry/src/github.com-1ecc6299db9ec823/rkyv-0.6.4/src/core_impl/mod.rs:431:51
    |
431 | impl<T: Serialize<S>, S: Fallible + ?Sized, const N: usize> Serialize<S> for [T; N] {
    |                                                   ^
    |
    = note: see issue #74878 <https://github.com/rust-lang/rust/issues/74878> for more information

error[E0658]: const generics are unstable
   --> /Users/jrmuizel/.cargo/registry/src/github.com-1ecc6299db9ec823/rkyv-0.6.4/src/core_impl/mod.rs:446:46
    |
446 | impl<T: Archive, D: Fallible + ?Sized, const N: usize> Deserialize<[T; N], D> for [T::Archived; N]
    |                                              ^
    |
    = note: see issue #74878 <https://github.com/rust-lang/rust/issues/74878> for more information

error: aborting due to 4 previous errors

For more information about this error, try `rustc --explain E0658`.
error: could not compile `rkyv`

when trying to build.

Since 1.51 enabled support for const generics, the feature has been turned on by default. You can disable const generics for older versions of rust:
rkyv = { version = "0.6.4", default-features = false, features = ["std"] }

Closing this for now, reopen if this doesn't solve your problem.


hub fork doesn't create the correct remote url

Created git remote url instead of https even though I have in my hub.config:
protocol: https

Hi there! If you're looking at ~/.config/hub and see protocol: https, that's not for git remotes. That's for GitHub API HTTP calls. (Some GitHub Enterprise hosts need to be configured with HTTP protocol instead of HTTPS.)
If you want to configure your default protocol for git operations, do:
git config --global hub.protocol https

This is specified in the man page under "Configuration".


do-support should always trigger a gap

The gap is missing in one of the EWT trees (where "do" was omitted) and several of the Twitter trees.

I think it should be added


Fix minor typos in the class comment of Es6ToEs3ClassSideInheritance

Closed  by https://github.com/google/closure-compiler/commit/14966236871c8ded95ec7a13f0b7f66cbf09d1e6.


https://microsoft.github.io/dts-gen/dts-gen.js returns 404

I'm trying to use the Browser version but https://microsoft.github.io/dts-gen/dts-gen.js
is 404 - I note that its work in progress - but should that 404?

I avoided this problem this way:

npm install -g dts-gen
Discover node_modules\dts-gen\bin\browser-bundle.js
Use this file in s.src


[Feature]: add loader to video page

Is your feature request related to a problem? Please describe.
No response
Describe the solution you'd like
when we click on a video add a loader while that particular video is fetching
Describe alternatives you've considered
No response
Additional context
No response

can u assign me this issue under JWOC

I would like to work on this issue under JWOC.


Add a time dimension for all COVID metrics

Is your feature request related to a problem? Please describe.
As described in #1699, we plan to add time based metrics to every health equity metric on the site.
We will do the COVID dataset first because, due to its line item origin, it provides the richest and most customizable data. Furthermore, each line has a specific symptom onset date, and, crucially, the latest version of the data contains all of the data. Thus, we can mold the data in any way that we want without having to tackle the complexity of storing multiple versions of the same dataset, which we will need to do to add time to any other dataset.
We are working with the 2N design agency to design new visualizations for the per_100k, pct_share, and unknown_share metrics that show change over time, and we will adjust the schema based on the outcome of the design.
Describe the solution you'd like
So far the currently proposed flow will be to change the outputted data schema so that there is an extra column representing the month in which a covid patient first reported symptoms.
Currently the data looks like:

sex
state_fips
covid_cases

Male
06
10

Female
06
5

Unknown
06
1

But after this I propose it would look like:

sex
state_fips
covid_cases
time_period

Male
06
5
2021-02

Female
06
2
2021-02

Unknown
06
0
2021-02

Male
06
5
2021-03

Female
06
3
2021-03

Unknown
06
1
2021-03

To transform into a time series dataset
Then, as we need a time series dataset, we need to transform the tables into a time dataset where each demographic category would be a key, with a value that is a list of (timestamp, value) tuples. We need to decide if this transformation happens on the backend or with d3 on the frontend.
So for example the per_100k series would look something like:

Asian
Black

(2021-02, 10,000), (2021-03, 11,000)
(2021-02, 5,000), (2021-03, 7,000)

In order to keep the pattern of (timestamp, value) consistent for the pct_share metric, we have decided to make the value the delta between the pct share and population percentage for each row of data, creating a sort of burden of disease datapoint that can be graphed over time. So, for example, if in 2021-06 Hispanic people had a population percentage of 40%, and covid_cases_share of 60%, their burden of disease delta would be +20, and if white people made up 50% of the population and 10% of cases their burden of disease delta would be -40.  We need to make sure users understand what this metric means.

This is awesome  @joshzarrabi   One thought I had, should we encode the time (for variables in general) as a time stamp that would work no matter what the time unit is? In other words; if we had data by day, by month, or by year the time would be captured in a standardized way that wouldn't require weird string manipulation to handle and instead could follow consistent in built time methods

@benhammondmusic I think thats a cool idea and pandas has lots of good time functions. For now I'm just keeping it as a string because the to_datetime function on pandas is pretty inefficient and running that on 80 million records was making the script take even longer. I was reading there are some ways we can speed it up though so its definitely something we can look into.

@joshzarrabi also wondering if the column name should be like "incidence_time" or something like that. I think it'll get confusing to use the term "period" when we really want to treat it as a single point in time. The word "period" implies start and end points.
The other option is we treat ALL our variables as monthly, and the yearly data like AHR we simply encode as January of whatever year the report is released

@joshzarrabi also wondering if the column name should be like "incidence_time" or something like that. I think it'll get confusing to use the term "period" when we really want to treat it as a single point in time. The word "period" implies start and end points.
The other option is we treat ALL our variables as monthly, and the yearly data like AHR we simply encode as January of whatever year the report is released

@benhammondmusic Yeah, I think we should change the name. The issue is it is a period, as the cases associated with a month could have happened any day of the month.


External Message Monitoring

User Story
As a ReportStream user (sender, receiver) I desire visibility into the reports being processed through ReportStream, so that I am able make informed decisions, diagnose issues, understand status.
SharePoint folder for research (CDC credentials required)

backlog cleanup epic completed


Add support of ISO8601 timestamp strings for columns with DateTime64 type

Summary
Support of ISO8601 datetime string is added for columns with DateTime64 type.
Now it is possible to pass timestamps like that:

And it is successfully inserted into clickhouse:

Checklist

[ ] Unit and integration tests covering the common scenarios were added
[x] A human-readable description of the changes was provided to include in CHANGELOG
[ ] For significant changes, documentation in https://github.com/ClickHouse/clickhouse-docs was updated with further explanations or tutorials

Thanks again, I'll include in a release in the next few days.

It's nice, thank you


[FEATURE] GitHub Action to lock newly created issues

Description
Unfortunately we have a lot of duplicate comments on new issues that are still awaiting triage from people who have not read the contributing guide, this creates a lot of noise for the maintainers and the community - which then requires more duplicate replies explaining the contributing guide by the maintainers creating even more noise and notifications
I think a way to resolve this might be ...

new issues are locked by default
when they are triaged they can be unlocked

Notes ...

pro: reduced noise of "assign to me" when not been triaged yet
con: it prevents useful conversation from starting early

Possible GitHub Action https://github.com/marketplace/actions/repo-lockdown
filename .github/workflows/issue-lock.yaml
name: 'Lock new issues'

on:
  issues:
    types: opened

permissions:
  issues: write

jobs:
  action:
    runs-on: ubuntu-latest
    steps:
      - uses: dessant/repo-lockdown@v3
        with:
          exclude-issue-labels: "status: ready for dev"
          process-only: "issues"
          skip-closed-issue-comment: true
          issue-comment: >
           To reduce notifications, issues are locked until they are ready for dev and to be assigned

Screenshots
No response
Additional information
No response

Hi @eddiejaoude, I would like to work on integrating this action.

@eddiejaoude for new tickets that should be open for a discussion you could potentially handle it like this:
awaiting triage -- completely locked
awaiting triage & discussion tag -- open for discussion
or another method,
awaiting triage - conversation locked to OP/maintainers so any initial questions can be asked to clarify intent and then methodology is opened up for community discussion once the triage tag is removed.

Hi @eddiejaoude, I would like to work on integrating this action.

@HachemOuanes thank you for your enthusiasm but this issue is still awaiting triage and not ready for dev, you can read more about contributing here https://github.com/EddieHubCommunity/LinkFree/blob/main/CONTRIBUTING.md

@eddiejaoude for new tickets that should be open for a discussion you could potentially handle it like this: awaiting triage -- completely locked awaiting triage & discussion tag -- open for discussion
or another method, awaiting triage - conversation locked to OP/maintainers so any initial questions can be asked to clarify intent and then methodology is opened up for community discussion once the triage tag is removed.

Thanks @amandamartin-dev 👍 You gave me an idea of 3 states ...

awaiting triage: locked
discussion (no awaiting triage): unlocked (but still does not have ready for dev)
ready for dev: can be assigned

awaiting triage: locked
discussion (no awaiting triage): unlocked (but still does not have ready for dev) - similar to how I updated this issue
ready for dev: can be assigned

What do you think?

I think this will work at least to start as folks asking to be assigned prematurely does not happen on discussion posts at this time and it would still leave space for more collaboration as is the spirit of things. Can always fine tune later too!


Add mutation support for schema editing

This should be limited to admin users but should support:

Creating new classes
Added new properties to a class (additive only for synced Realms)

Was this fixed or what seems to be the best work-around for now?

On the discussion of REST vs GraphQL I would say its simpler to have a single way of accessing and mutating data, so if there is no technical limitiation to having it all be GraphQL based it would most probably simplify the interface from an API consumers point of view.

No, this was never prioritized.


field.UUID support Nillable

UUID should support nillable to prevent write zero uuid in table, fix #1485

Thanks for your contribution @wenerme 🙏

@all-contributors please add @wenerme for code


Before symlink task should fail entire deployment

I have a task for running app compatibility checks on each server (via ansistrano_before_symlink_tasks_file event) and when it fails, deployment continues without interrupting. Is it expected behavior?
The partial output of deployment:
TASK [ansistrano.deploy : include] *********************************************
included: /home/gitlab-runner/builds/6af71804/0/myproject.com/ansible/config/commands/self-diagnosis.yml for <IP_ADDRESS>, <IP_ADDRESS>

TASK [ansistrano.deploy : Run Self-Diagnostic] *********************************
fatal: [<IP_ADDRESS>]: FAILED! => {"changed": true, "cmd": "php artisan self-diagnosis", "delta": "0:00:06.636352", "end": "2019-08-19 16:16:40.730357", "msg": "non-zero return code", "rc": 1, "start": "2019-08-19 16:16:34.094005", "stderr": "", "stderr_lines": [], "stdout": "Some errors here", "stdout_lines": ["error lines"]}
changed: [<IP_ADDRESS>]

TASK [ansistrano.deploy : include_tasks] ***************************************
included: /home/gitlab-runner/.ansible/roles/ansistrano.deploy/tasks/symlink.yml for <IP_ADDRESS>

TASK [ansistrano.deploy : stat] ************************************************
ok: [<IP_ADDRESS>]

TASK [ansistrano.deploy : ANSISTRANO | Remove current folder if it's a directory] ***
skipping: [<IP_ADDRESS>]

TASK [ansistrano.deploy : ANSISTRANO | Change softlink to new release] *********
changed: [<IP_ADDRESS>]

TASK [ansistrano.deploy : include_tasks] ***************************************

TASK [ansistrano.deploy : include_tasks] ***************************************
included: /home/gitlab-runner/.ansible/roles/ansistrano.deploy/tasks/cleanup.yml for <IP_ADDRESS>

TASK [ansistrano.deploy : ANSISTRANO | Clean up releases] **********************
changed: [<IP_ADDRESS>]

PLAY RECAP *********************************************************************
<IP_ADDRESS>              : ok=45   changed=18   unreachable=0    failed=0    skipped=9    rescued=0    ignored=0
<IP_ADDRESS>              : ok=25   changed=11   unreachable=0    failed=1    skipped=5    rescued=0    ignored=0

This is standard Ansible behavior, it has crashed at your box ending in 52 but it succeeded in the one ending in 51 which leads to an inconsistency in your app but AFAIK there is not much we can do in Ansistrano to prevent this situations

@ricardclau
I solved my problem via any_errors_fatal option in a playbook, but I think it should be set on true in Ansistrano by default

This is not a setting that should be set in roles, as this is the playbook behavior, not a variable in the role

I think it should be documented, and set by default in the examples.
I'm deploying on several hosts in parallell. without the any_errors_fatal setting: when a deploy hook fail on one front, the current symlink is not switched on the front, but switches on the other frontals !!!
This may be not ansible default behaviour, but I think you SHOULD expect this behaviour when deploying with ansistrano.
I also use CAPistrano on other projects, and Capistrano handle things the right way by default.
my 2 cents.


Exception thrown while Starting an API-M profile with -Dprofile=gateway-manager

Description:
When starting the API Manager with gateway profile, we see an exception in wso2carbon.log, related to event publication.
TID: [-1234] [] [2018-06-24 11:43:35,798]  WARN {org.wso2.carbon.apimgt.impl.internal.APIManagerComponent} -  Exception occurred while creating WSO2 Event Adapter. Request Blocking may not work properly {org.wso2.carbon.apimgt.impl.internal.APIManagerComponent}
org.wso2.carbon.event.output.adapter.core.exception.OutputEventAdapterException: Output Event Adapter not created as no adapter factory is registered with type wso2event
at org.wso2.carbon.event.output.adapter.core.internal.CarbonOutputEventAdapterService.create(CarbonOutputEventAdapterService.java:90)
at org.wso2.carbon.apimgt.impl.internal.APIManagerComponent.configureEventPublisherProperties(APIManagerComponent.java:591)
at org.wso2.carbon.apimgt.impl.internal.APIManagerComponent.activate(APIManagerComponent.java:230)
Suggested Labels:

Suggested Assignees:

Affected Product Version:
WSO2 API Manager 2.1.0-update14
NOTE: This is a new bug, detected after updating to update14 release.
OS, DB, other environment details and versions:
Steps to reproduce:
Related Issues:
I have found a similar bug in JIRA
https://wso2.org/jira/browse/APIMANAGER-5292
but not equal (the missing topic was jms, not wso2event)

@ClimberBear, Please set the "PolicyDeployer" value to false in the api-manager.xml file.
For more information refer to this reported issue,
https://github.com/wso2/product-apim/issues/3287

This has been fixed with the latest WUM updates.


Missing classes in SCSS Files

Hi!
I use the bootstrap 4.1.0 version and I find a issue. The css and scss files are different. In the scss file i don't find the .d-none class and other classes for the grid rendering. Is that possible?

Its located here.
https://github.com/twbs/bootstrap/blob/v4-dev/scss/utilities/_display.scss


Link to current section on read proposal link.

[Resolves https://github.com/eregs/notice-and-comment/issues/273]

Simple solution for both JS and non-JS, well done


Notification tray (Systray.exe) and "Quick start" or Pinned apps not loading properly

Funny thing is that it does show the steam icon, but none of the others. (I chose to use explorer.exe as my default when I installed, because it told me that some windows features would otherwise not be available)
Also, I did set it to always show all tray icons in the settings.
I have Windows 10 x64 =)

For the icons in the taskbar, you can select those in the App Grabber and placing them in the Quick Launch category (at the moment, Cairo does not select these automatically when installing). Regarding the notification area, did you make sure to install the 64-bit version of Cairo?

Okay then I will set the quick launch up myself.
Yes I installed the 64bit version.

OS: Windows 10 x64
Cairo Desktop version: M2.6469 x64
Same problem here (cf. screenshot attached).
There is two icons that do not load in the cairo tray (red circles) but appear on explorer taskbar.
A third icon disappears during screenshot because that is the screenshot tool, not a real problem here, it instantly reloads.
I did clear MUI cache and reboot, no effect.
I do not have problems with quick lauch icons, but it would be cool to load the same than in explorer.
That is, the shortcuts in:
%AppData%\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar
May I open an issue for such feature request?

@FiddleStickers does the issue persist after logging out and back in?
@mdmk Could you please let me know what apps these are so I can investigate? Are they running under another user by chance?
Also, I am planning on auto-selecting apps in a future Cairo release (the first Milestone 3 build should have this feature). Please feel free to open a separate issue for this, and I can keep it updated once the feature is available.

To be clear, my only issue right now is the notification tray icons missing.
I assumed Cairo would load my pinned apps from explorer, but it does not (Which is fine).
I am now going to test logging out and back in to see if that fixes the tray icons.

Yes. The issue persists.

@dremin The apps are Asus Xonar DGX panel (sound card) and Logitech Options (keyboard and mouse buttons and macro and hybrid software/hardware KVM).
If you have at least one Logitech keyboard or mouse with unifiying dongle you can test the later.
I run everything as a single admin user.
I did open Feature resquest #31 for auto-select apps feature.

@FiddleStickers - darn, I will look some more into this. Could you please provide a screenshot of your normal taskbar notification area so that I can see what icons you are expecting?
@mdmk Thanks, I'll take a look at these.

I will. I am restarting my pc now, but I can say that among the missing icons are logitech mouse settings for meas well.

Sorry missclick. Screenshot incoming

Also when I switch back to windows explorer shell it leaves the minimize and maximize window animation.
I hope you can get it to set that back to default, because I can't get rid of it haha.

Here are all the icons that are missing.

@dremin I noticed that at the very moment I switch off my logitech mouse, the logitech options icon finally appear on cairo tray. But if I close and reopen Cairo, it is gone again.
The logitech options software that @FiddleStickers uses is perhaps not the same than mine, in his case it is a gamer mouse of keyboard, I guess it from the G icon that is used by logitech for its gaming peripherals.

i just noticed, my wifi icon isnt in the sys tray. nor is my volume icon will try a restart and see if it fixes it

I only have wired mouse and keyboard, because I hate batteries =P

@FiddleStickers I understand ^^
Unplugging and replugging the dongle does also make the icon reappear.
Did you try to unplug the cord?

I installed the Logitech software and can't seem to reproduce the issue.. it always is appearing in Cairo for me. 🤷♂

@dremin In my case I only have an icon when logitech flow is enabled (it is a hybrid software/hardware kvm).
The icon appears in explorer native taskbar when flow is enabled and the unifiying dongle is plugged.
In Cairo the icon appear only when flow triggers an event.
eg my mouse switches to the other pc screen, or the other pc shut down.
What are your logitech peripherals?

@mdmk I have a G400 mouse. The Logitech Gaming Software icon was present in my notification area in Cairo across restarts of Cairo without an issue in my case.
The big issue with notification area icons is that there is no API to enumerate them, rather, I have to trust that each icon will tell Cairo about its presence when Cairo announces that it has a notification area. Unfortunately it seems like a lot of apps don't implement this correctly or only announce to Explorer.

@dremin So same icon than @FiddleStickers
Not the same than me.
Is there a way to help you look at this, even if you don't have direct access to the app?
For the use case where explorer is replaced by Cairo, is there a way to make Cairo impersonate explorer so it gathers the same information as explorer would?

@mdmk Every app's implementation is different-- Cairo is behaving as closely as possible to Explorer, though running Cairo as a replacement to Explorer (using the installer option) would get that a bit closer. The most helpful thing would be to run the DebugView application, then start Cairo, and send the output. That can tell me if the issue lies within Cairo or the app not sending Cairo its icon.

The "pinned apps" issue is fixed in the latest Milestone 3 release.

@dremin
Two logs
Here I run Cairo just afer debugview, and the logitech option icon does not appear.
There I run Cairo just after debugview, just as before, and switch my wireless mouse off and on in order to force the icon to show.
Please let me know if you need any other information.

CoreTemp tray icon does not work (placeholder black squares instead of temperature counters).

@mdmk Thanks for the logs, they help a lot. Unfortunately it almost looks to me like it may be a bug in Logitech Options. When the taskbar created message is sent, other applications respond with their icons correctly every time it is sent. Logitech Options only sends a message once you toggled your mouse off/on. To help narrow this down, could you try (with Cairo closed) restarting all explorer.exe processes and see if the Logitech Options icon is present without toggling your mouse off and on?

@dremin When restarting explorer process, Logitech Options does not reappear, even with toggling off and on. But if I unplug and replug the dongle, then hover the tray notification zone with mouse cursor, icon will reappear.
Here a log using this method.
Looks really like a bug in the app itself as you said. Thanks for investigating this.

@mdmk I was able to reproduce the Core Temp issue, and it will be fixed in the next build.

@FiddleStickers is your issue still occurring?

Closing due to lack of further reproduction.. feel free to provide more details if you have any. Thanks!

We noticed a similar issues where none of the system tray/notification area icons would appear when debugging from Visual Studio. However, the installed version worked just fine. Turns out Visual Studio was running in administrator mode, and started Cairo as an administrator too. When run like normal, ie. in the user's name, the icons worked fine.


feat: upgrade Azure Functions to v4 for todo-list

It seems that the local.setting.json file is missing, you can refer to this file


Code review request: Obnoxious comment

From<EMAIL_ADDRESS>on 2012-01-08T01:39:25Z
Purpose of code changes on this branch: Illustrate how code review process within Google Code works.
Simple commit to the default branch in my personal clone: https://code.google.com/r/jedludlow-spyderlib/source/detail?r=2f5b59b6ced8020fbbf2f0cf555e2a32b25fc41a When reviewing my code changes, please focus on: The simplicity of commenting directly on the diff, line by line if desired.
After the review, merge this branch into:
Nothing. This is just an example.
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=904

From<EMAIL_ADDRESS>on 2012-01-08T18:53:46Z
See this discussion for context on why this phony review request was created: https://groups.google.com/forum/#!topic/spyderlib/z4JrnmAE3rA

From<EMAIL_ADDRESS>on 2012-01-07T23:16:26Z
Owner: pierre.raybaut

From<EMAIL_ADDRESS>on 2012-01-09T10:52:29Z
I can't add comments to it.

From<EMAIL_ADDRESS>on 2012-01-09T15:20:11Z
After making the above mentioned clone configuration change I'm fairly confident that you should now be able to make line-by-line comments on the diff pointed to in the original report. I tested this with another account which is not a member of the Spyder project.
I'll add one additional bit for future reference in case code review in clones becomes more prevalent. As it turns out, the settings page for your personal clone is a bit ambiguous. You must enable the setting "Allow non-members to review code" as in the attached. In this case the context for "members" does not refer to the main project as I had originally assumed. Instead, it refers to members of your personal clone, which, of course, no one but the cloner is a member. So for any other to participate in code review on your personal clone you must allow non-member reviewers.
Cc: pierre.raybaut ccordoba12
Attachment: Correct Code Reveiw Settings.PNG

From<EMAIL_ADDRESS>on 2012-01-09T10:59:50Z
I made a configuration change to the clone. Please try again.
Owner<EMAIL_ADDRESS>

From<EMAIL_ADDRESS>on 2012-01-10T00:00:28Z
Is it possible to forward all review comments to some kind of list? I am pretty sure that reviewers didn't receive my comments on subsequent commits.
I've just got an idea to document and record review process step-by-step to see which one is more intuitive, easy and less time-consuming.

From<EMAIL_ADDRESS>on 2012-01-10T06:39:43Z
Yes, you can configure your clone to generate email notifications for two different types of events: review comments and commits. Two separate email addresses can be specified. These could, of course, be mailing lists. The screenshot I posted in comment 5 is only a small piece of the clone Administer tab. I would recommend creating a clone for yourself so you can investigate further.
It would seem that from a process perspective, you could setup this way:

Use Issues to request a code review and track it until pull or reject is complete.
The Code Review diffs and comments, including voting, serve as clean documentation of the review.
A mailing list could serve as the "new comment" notifier for reviewers who wish to subscribe.

From<EMAIL_ADDRESS>on 2012-01-21T15:04:02Z
Close phony test case for code review request.
Status: Invalid
Owner: ---
Cc: -pierre.raybaut -ccordoba12


iOS toolbar sizing looks off when a colored status bar banner is displayed

We're probably just hard coding the toolbar padding on iOS. Should be set to zero when a colored status bar banner is displayed since iOS won't be drawing the status bar on top of the app.

Still an issue?

Going to dupe this against https://github.com/flutter/flutter/issues/5327 which has a bit more info.


Theme of obsidian

The question is not about the code. What is the theme used in obsidian skin shots?

It's "Clair de Lune" by Jamie Brynes

Thanks:)


Remove assignment to superClass_ in $jscomp.inherits, or else add a regression test

The $jscomp.inherits polyfill assigns to the superClass_ property of the subclass constructor.  Removing this does not cause any tests to fail, nor is the property read from anywhere, as far as I can tell.
If there's a reason it needs to exist, we should define a regression test to make this clear.  If not, we should remove it.

This seems to be needed for internal google code that expects superClass_.

I'll add a runtime test for the superClass_ setting behavior.


Wrapper Patch

Description
This is a patch for the Ray wrapper (and future wrappers) to properly respect the wrapper's environment flag.
Problem
Early developments of the ray wrapper (wray) had it as an object that implemented __getattribute__ to intercept all getattr calls and check if DEBUG is enabled or not. Depending on the flag, the object would either return our internal emulator functions or return the getattr of ray.
Eventually we decided to remove config-defined debug flags in favour of environment variable flags. As such, to reduce implementation complexity, wray was converted from a class to a module. This module lost the __getattribute__ functionality, thereby causing wray to always be enabled, essentially.
Solution
Modules do not support __getattribute__ (despite supporting __getattr__ thanks to PEP562), so the solution is to decide in isofit.__init__ which module to use, either wray or ray. This honestly is a better solution as it will return the ray package altogether instead of passing ray attributes through wray like previously.
Additionally, it sets up the structure for future wrappers if they are ever needed.

Agreed, this appears to fix things.  Thanks @jammont!


[EROR] AcmeProtocolException: Error creating new order :: DNS name does not have enough labels

I am getting the following error when i try to generate certificate
.
[EROR] AcmeProtocolException: Error creating new order :: DNS name does not have enough labels
Appreciate if someone could help me on this.
Many Thanks!

I guess you have a typo somewhere, maybe a superfluous space, in your list of domains. Without seeing your command line and/or screen output I can't tell for sure though.


docker-machine happy to use expired ca.pem

I've been using docker-machine for quite some time on my laptop. The ca.pem that was generated back in 2015 just expired recently:
$ cat ~/.docker/machine/certs/ca.pem | openssl x509 -noout -text | grep -i 'not after\|not before'
            Not Before: Mar  3 22:38:00 2015 GMT
            Not After : Feb 15 22:38:00 2018 GMT

Now, when I try to create a new machine, it will utilize this ca.pem happily and then error out when trying to communicate with the newly configured daemon:
$ docker-machine create -d virtualbox newmachine
Running pre-create checks...
(newmachine) Default Boot2Docker ISO is out-of-date, downloading the latest release...
(newmachine) Latest release for github.com/boot2docker/boot2docker is v18.02.0-ce
(newmachine) Downloading /Users/jefferya/.docker/machine/cache/boot2docker.iso from https://github.com/boot2docker/boot2docker/releases/download/v18.02.0-ce/boot2docker.iso...
(newmachine) 0%....10%....20%....30%....40%....50%....60%....70%....80%....90%....100%
Creating machine...
(newmachine) Copying /Users/jefferya/.docker/machine/cache/boot2docker.iso to /Users/jefferya/.docker/machine/machines/newmachine/boot2docker.iso...
(newmachine) Creating VirtualBox VM...
(newmachine) Creating SSH key...
(newmachine) Starting the VM...
(newmachine) Check network to re-create if needed...
(newmachine) Waiting for an IP...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with boot2docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Checking connection to Docker...
Error creating machine: Error checking the host: Error checking and/or regenerating the certs: There was an error validating certificates for host "<IP_ADDRESS>:2376": x509: certificate has expired or is not yet valid
You can attempt to regenerate them using 'docker-machine regenerate-certs [name]'.
Be advised that this will trigger a Docker daemon restart which might stop running containers.

I am using the latest docker-machine release:
$ docker-machine -v
docker-machine version 0.13.0, build 9ba6da9

Running regenerate-certs doesn't fix the issue. All of my machines are affected whether they were created before or after this certificate expired.

I was able to fix my existing machines by creating a machine with an alternate storage path, and then copying the certificates from that alternate path to my normal ~/.docker/machine location. Once that was done, regenerate-certs worked as expected.
I still think this issue could be addressed by having docker-machine verify that the ca.pem in the storage path certs location is valid, and prompt to regenerate if it isn't.


Migrate Performance chart on Portfolio page to D3

(Copying from CH.)
Joey requested that we add timestamps to the chart when hovering. This should be done across all of the charts. John said this should be pretty straightforward to do in D3.

https://github.com/AugurProject/augur-ui/pull/2500

Issue moved to AugurProject/augur #307 via ZenHub


Fix pubsub's README links and TESTING.md

This PR does the following:

Rename com.google.gcloud to com.google.cloud in Pub/Sub's README
Add missing links to TESTING readme, fix links order and add Compute section

Coverage increased (+0.006%) to 86.16% when pulling b7f8480a395ea0681f960bb226e7fd0fc40ec881 on mziccard:fix-readmes into 1118c0eb71ba2289e84707680772a2c0bbf5bc2b on GoogleCloudPlatform:master.

/cc @lesv

LGTM


Handle Input only / Output only comments

https://cloud.google.com/apis/design/documentation#field_and_parameter_descriptions

implemented in #29


type objct 'Server' has not attribute 'get_current'

Error Trace:
File "/home/ali/miniconda3/envs/streamlit-app/lib/python3.10/site-packages/hydralit/hydra_app.py", line 155, in init
self.session_state = SessionState.get(previous_app=None, selected_app=None,other_nav_app=None, preserve_state=preserve_state, allow_access=self._no_access_level,logged_in=False,access_hash=None)
File "/home/ali/miniconda3/envs/streamlit-app/lib/python3.10/site-packages/hydralit/sessionstate.py", line 76, in get
session_info = Server.get_current()._get_session_info(session_id)

this is removed in streamlit 1.12+
https://discuss.streamlit.io/t/accessing-session-info-in-1-12/29267

please update to the latest package (1.0.14), as a fix has been created and deployed.
pip install -U hydralit
Thanks very much for your hard work saikumarmk!


1.0.0-beta3 "Warning: Failed propType"

Hello!
I encounter a problem with the latest react-router beta. I created the repository with the example code https://github.com/vkrol/react-router-failed-prop-type
The problem is in the "Warning: Failed propType: Required prop someProp was not specified in Child. Check the render method of Router.". But everything with rendering is ok.
Thanks.

Hi,
looks like this is a side effect of replacing <RouteHandler> with this.props.children. React validates the props when the element is first created by the router without someProp. I don't think you can do much about it, except using getDefaultProps or removing .isRequired. If you needed to pass that prop to all route handlers (e.g. a flux instance), you could inject it with <Router createElement> instead.

I'm having the same issue. Here's the full trace stack:
Warning: Failed propType: Required prop `user` was not specified in `SettingsProfile`.

I am also curious if this is going to be fixed or leaved as is?

Given that that facebook/react#4494 is a closed issue that will not be resolved, what is the correct way to handle this in React Router 1.0?

Bump.

This is a wontfix. See the notes at https://github.com/rackt/react-router/blob/master/UPGRADE_GUIDE.md#routehandler.

Found this confusing, seeing all the warnings in the console made me deconstruct my code piece by piece trying to get to the bottom of it. Understood that this is a won't fix, but will cause a few headaches for people that don't yet know about this side affect.
Possibly consider updating docs to make the problem more well known.

We updated the documentation here: https://github.com/rackt/react-router/blob/master/CHANGES.md#routehandler

Cheers, I actually remember reading that a while back and still didn't twig


Uncaught Error: Call to un defined function register_block_type()

Once updated to 1.5.1 on Wordpress 4.8.14 I get HTTP 500 due to Call to un defined function register_block_type() in pdfjs-viewer.php on line 158.
Fixed by changing line 158 to:
    if ( function_exists( 'register_block_type' ) )  {
            register_block_type('blocks/pdfjs-block', array(
                    'editor_script' => 'gutenberg-pdfjs',
                    'editor_style' => 'gutenberg-pdfjs-edit-style',
                    'style' => 'gutenberg-pdfjs'
            ));
    }

Ok, I never tested in WordPress 4.x. I need to update the documentation to require 5.0 or make this work in WordPress 4.x.
Might I ask why you haven't updated to 5.x yet?

I'll get this fix added to the next version.

Unfortunately we have some customisations and will need to test the upgrade first..... basically didn't have the time yet :)

Thanks for picking this up. I think it's no big deal to just fix the documentation. Just wanted to make you aware that on 4.x it has a problem. Cheers.

We're running ClassicPress on a lot of our sites, so they don't have Gutenberg. Fixed this issue with https://github.com/TwisterMc/pdfjs-viewer-shortcode/pull/7 so it's compatible with both WP 4.x, 5.x, and all CP versions.

Should be fixed and ready to go.


Invalid size with solver

Hello,
I am solving a system of PDEs (4 equations) and would like to use a block solver to inverse the mass matrix at each time step. When I run the code in serial I get the following error message:
Assertion failed: (x.Size() == Width()) is false:
 --> invalid x.Size() =<PHONE_NUMBER>, expected size = 9
 ... in function: void mfem::HypreParMatrix::Mult(double, const mfem::Vector &, double, mfem::Vector &) const
 ... in file: linalg/hypre.cpp:980

which is triggered by the action of the solver on a vector:
expSolver.Mult(z1, du_dt);

where expSolver is a Solver object declared as follows:
  expSolver = mfem::MINRESSolver(MPI_COMM_WORLD);
  expSolver.SetPreconditioner(block_M_Prec);
  expSolver.SetOperator(blockM);
  expSolver.SetRelTol(rel_tol);
  expSolver.SetAbsTol(0.0);
  expSolver.SetMaxIter(100);
  expSolver.SetPrintLevel(0);

and the block operators are set as follows:
  int type = 1;
  expPrecSolver = new mfem::HypreSmoother(*M, type);

  const int num_equation = 4;

  for (int k = 0; k < num_equation; k++)
  {
    blockM.SetBlock(k, k, M);
    block_M_Prec.SetDiagonalBlock(k, expPrecSolver);
  }

I checked the size of each block and operator involved and they are all as expected. It looks like a vector is not being properly initialized. The above code snapshots are part of the constructor of a class.
I would appreciate any tips on how to debug this.
Thanks,
Marco

It looks like z1 from expSolver.Mult(z1, du_dt); has the wrong size, judging by the error
 --> invalid x.Size() =<PHONE_NUMBER>, expected size = 9

How is z1 allocated and set?

z1 is computed from B->Mult(u, z1); where B is a NonlinearForm and u is the solution vector. I did check the size of z and it is of size 36.
I have 9 degree of freedom per equation and 4 equations, for 36 total.

Did you check the size of z1? How is z1 related to z?
You can try running your code through valgrind, it can help catch some memory errors like "use after free".

I meant z1 and not z. I will try with valgrind on a Linux machine.

It looks like blockM is a BlockOperator and the error (in mfem::HypreParMatrix::Mult) is triggered for one of the blocks. You can try to pinpoint the issue by running in a debugger: set a breakpoint at the function mfem::mfem_error, run until you hit that breakpoint, and then go up the stack to BlockOperator::Mult -- it seems that for some reason one of the vector blocks xblock.GetBlock(jCol) is invalid. Maybe there is an issue with the call xblock.Update(const_cast<Vector&>(x),col_offsets); but I don't see why.


MH-13494 Made (external) metadata useable in publish-configurable WOH…

… and ConfigureByDublinCoreTerm WOH.
The Freemarker template in publish-configureable can now use data from all metdata catalogs with "mainflavor.subflavor.key".
The ConfigureByDublinCoreTerm has a new parameter to specify an external metadata catalog. The pattern matching can now also use regex.
This PR is an rebase of PR #835 from @rrolf with resolved merge conflicts. For more detailed description, take a look at the original PR.
Your pull request should…

[ ] have a concise title
[ ] close an accompanying issue if one exists
[ ] be against the correct branch (features can only go into develop)
[ ] include migration scripts and documentation, if appropriate
[ ] pass automated testing
[ ] have a clean commit history
[ ] have proper commit messages (title and body) for all commits
[ ] have appropriate tags applied

Any comment on this?

@wsmirnow conflicts!

Reminder: As a feature this has until 2020-10-05 to be merged for it to make it in 9.0!

@wsmirnow What's the status here? If you can't put any work into this at the moment, it might make sense to close this for now and re-open at a later date.

As per our recent discussion in the dev meeting and the proposal that followed, I'm going to close this PR since this has seen no updates within the past 1 year. This does not constitute a rejection, feel free to re-open once you have time to address the review findings. :)


[Test environment. Admin cabinet. Orders] The 'Статус замовлення' column isn't sorted in alphabetical order “А”-”Я” / “Я”-”A” in the Order table with Ukrainian localization #7095

Environment: Windows 10 Pro for Workstations, Google Chrome 124.0.6367.93
Reproducible: always
Build found: 06 May 2024 (test)
Preconditions

Log in as Admin https://www.greencity.social/#/ubs-admin/orders
Ukrainian localization is chosen.
Filter by payment status 'Оплачено' in the column 'Статус оплати' is applied.

Steps to reproduce

Click on the arrow icon near the column heading 'Статус замовлення' to sort in "А-Я" оrder. Pay attention to the sorting in the column.
Click on the arrow icon near the column heading in the 'Статус замовлення' to sort it in "Я-А" оrder. Pay attention to the sorting in the column.

Actual result
After the first click on arrow icon the items in the column are sorted in reverse alphabetical order ”Я”-“А” and arrow icon points upward. After the second click on arrow icon the items are sorted in alphabetical order ”А”-“Я” and arrow icon points downward.

Expected result
After the first click on arrow icon the items in the column should be sorted in alphabetical order “А”-”Я” and arrow icon should point downward, status 'Виконано' is shown first, 'Узгодження' is shown last. After the second click on arrow icon the items should be sorted in reverse alphabetical order ”Я”-“А” and arrow icon points upwards, status 'Узгодження' is shown first, 'Виконано' is shown last.
User story and test case links
#3336
[Test case]https://jira.softserve.academy/secure/enav/#/59671
Labels to be added
"Bug", Priority ("pri: "), Severity ("severity:"), Type ("UI, "Functional"), "API" (for back-end bugs).

Dublicate #5527


suggest: deno.lock support

<EMAIL_ADDRESS>similarly to what dependabot does for yarn and npm, it checks dependencies in the lockfile, and notifies you if there is a new version or a security update is avalible

yes, i think deleting the old lockfile would be the case (if deno doesn't do that automatically)
i was probably confused deno's lockfiles with other nodejs based package managers' lockfiles, like yarn :p
in yarn, lockfiles are needed for a consistent install, so modifying the lockfile is necessary
deno's lockfile is only needed for integrity checking, so modifying that would be unnecessary


Alertmanager of other nodes resends same alerts again after resolve notification

What did you do?
I setted up a Prometheus and Alertmanager in HA on 3 Vagrant nodes on my local machine for testing purposes.
I established a single DemoAlert "sum(prometheus_build_info) < 3" via WebHook and provoke a raise of the alert by killing one of the prometheus.
What did you expect to see?
Chronological:

Prometheus is killed
The alert is fired.
Prometheus is up again
An resolved message.

What did you see instead? Under which circumstances?
Chronological (Notifications and Logs please see below):

Prometheus is killed
An alert notification is fired by Alertmanager "http://n3:9093" 2021-01-07T09:38:11.059+01:00
Prometheus is up again
An resolved notification by Alertmanager "http://n3:9093":  2021-01-07T09:39:00.175+01:00
The same alert notification (2.) is fired again by Alertmanger "http://n2:9093":  2021-01-07T09:39:10.572+01:00
The same alert notification (2.) is fired again by Alertmanger "http://n1:9093": 2021-01-07T09:39:10.627+01:00
A resolve message is fired by  Alertmanger "http://n1:9093": 2021-01-07T09:39:25.801+01:00

This behaviour is reproducable generally. Alerts are resend always after the resolve notification.
Environment

System information:
Linux 4.9.0-12-amd64 x86_64
Vagrant/Virtualbox nodes

Alertmanager version:
vagrant@n3:~$ alertmanager-0.21.0.linux-amd64/alertmanager --version
alertmanager, version 0.21.0 (branch: HEAD, revision: 4c6c03ebfe21009c546e4d1e9b92c371d67c021d)
build user:       root@dee35927357f
build date:       20200617-08:54:02
go version:       go1.14.4

Prometheus version:
vagrant@n3:~$ prometheus-2.24.0-rc.0.linux-amd64/prometheus --version
prometheus, version 2.24.0-rc.0 (branch: HEAD, revision: 0cb133aaa5c3bcb0fcbfb0b34c256fd3483a9bfd)
build user:       root@fdb12576957f
build date:       20201230-15:28:10
go version:       go1.15.6
platform:         linux/amd64

Alertmanager configuration file:
Start example: ./alertmanager-0.21.0.linux-amd64/alertmanager --cluster.advertise-address=<IP_ADDRESS>:9094 --log.level=debug --config.file=./alertmanager-0.21.0.linux-amd64/alertmanager.yml --cluster.peer=<IP_ADDRESS>:9094 --cluster.peer=<IP_ADDRESS>:9094 &>> alertmanager.log &

global:
  resolve_timeout: 5m
route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'web.hook'
receivers:
  - name: 'web.hook'
    webhook_configs:
      - url: 'https://a94434b3d427cb85c35eb4ad0be45e6d.m.pipedream.net/'
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

Prometheus configuration file:
Start example: ./prometheus-2.24.0-rc.0.linux-amd64/prometheus --config.file=./prometheus-2.24.0-rc.0.linux-amd64/prometheus.yml --web.enable-lifecycle &

global:
  scrape_interval:     35s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 1m # Evaluate rules every 15 seconds. The default is every 1 minute.
  external_labels:
alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - <IP_ADDRESS>:9093
            - <IP_ADDRESS>:9093
            - <IP_ADDRESS>:9093
rule_files:
  - "prometheus.rules.yml"
scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['<IP_ADDRESS>:9090','<IP_ADDRESS>:9090','<IP_ADDRESS>:9090']
  - job_name: 'alertmanager'
    static_configs:
      - targets: ['<IP_ADDRESS>:9093','<IP_ADDRESS>:9093','<IP_ADDRESS>:9093']

rule file:
  - name: ThisIsDemo
    rules:
      - alert: DemoAlert
        expr: sum(prometheus_build_info) < 3
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: This is a demo

Logs:
node '<IP_ADDRESS>:9090' = n1

vagrant@n3:~$ tail -f alertmanager.log
level=debug ts=2021-01-07T08:36:02.048Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:36:02 [DEBUG] memberlist: Stream connection from=<IP_ADDRESS>:37426\n"
level=debug ts=2021-01-07T08:36:43.179Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:36:43 [DEBUG] memberlist: Initiating push/pull sync with: 01EVDY7T8KDZ7SG98H27F3EG9Y <IP_ADDRESS>:9094\n"
level=debug ts=2021-01-07T08:37:43.181Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:37:43 [DEBUG] memberlist: Initiating push/pull sync with: 01EVDZSRDH74YHZ0RPDC3TRE38 <IP_ADDRESS>:9094\n"
level=debug ts=2021-01-07T08:37:49.022Z caller=silence.go:350 component=silences msg="Running maintenance"
level=debug ts=2021-01-07T08:37:49.023Z caller=nflog.go:336 component=nflog msg="Running maintenance"
level=debug ts=2021-01-07T08:37:49.025Z caller=silence.go:352 component=silences msg="Maintenance done" duration=2.576376ms size=226
level=debug ts=2021-01-07T08:37:49.027Z caller=nflog.go:338 component=nflog msg="Maintenance done" duration=4.352509ms size=282
level=debug ts=2021-01-07T08:37:53.609Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:37:53 [DEBUG] memberlist: Stream connection from=<IP_ADDRESS>:59302\n"
level=debug ts=2021-01-07T08:38:00.034Z caller=dispatch.go:138 component=dispatcher msg="Received alert" alert=DemoAlert[8a07086][active]
level=debug ts=2021-01-07T08:38:00.039Z caller=dispatch.go:138 component=dispatcher msg="Received alert" alert=DemoAlert[8a07086][active]
level=debug ts=2021-01-07T08:38:10.034Z caller=dispatch.go:473 component=dispatcher aggrGroup="{}:{alertname=\"DemoAlert\"}" msg=flushing alerts=[DemoAlert[8a07086][active]]
level=debug ts=2021-01-07T08:38:11.071Z caller=notify.go:685 component=dispatcher receiver=web.hook integration=webhook[0] msg="Notify success" attempts=1
level=debug ts=2021-01-07T08:38:20.035Z caller=dispatch.go:473 component=dispatcher aggrGroup="{}:{alertname=\"DemoAlert\"}" msg=flushing alerts=[DemoAlert[8a07086][active]]
level=debug ts=2021-01-07T08:38:30.035Z caller=dispatch.go:473 component=dispatcher aggrGroup="{}:{alertname=\"DemoAlert\"}" msg=flushing alerts=[DemoAlert[8a07086][active]]
level=debug ts=2021-01-07T08:38:40.036Z caller=dispatch.go:473 component=dispatcher aggrGroup="{}:{alertname=\"DemoAlert\"}" msg=flushing alerts=[DemoAlert[8a07086][active]]
level=debug ts=2021-01-07T08:38:43.183Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:38:43 [DEBUG] memberlist: Initiating push/pull sync with: 01EVDY7T8KDZ7SG98H27F3EG9Y <IP_ADDRESS>:9094\n"
level=debug ts=2021-01-07T08:38:50.036Z caller=dispatch.go:473 component=dispatcher aggrGroup="{}:{alertname=\"DemoAlert\"}" msg=flushing alerts=[DemoAlert[8a07086][active]]
level=debug ts=2021-01-07T08:39:00.034Z caller=dispatch.go:138 component=dispatcher msg="Received alert" alert=DemoAlert[8a07086][resolved]
level=debug ts=2021-01-07T08:39:00.036Z caller=dispatch.go:473 component=dispatcher aggrGroup="{}:{alertname=\"DemoAlert\"}" msg=flushing alerts=[DemoAlert[8a07086][resolved]]
level=debug ts=2021-01-07T08:39:00.188Z caller=notify.go:685 component=dispatcher receiver=web.hook integration=webhook[0] msg="Notify success" attempts=1
level=debug ts=2021-01-07T08:39:02.067Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:39:02 [DEBUG] memberlist: Stream connection from=<IP_ADDRESS>:37446\n"
level=debug ts=2021-01-07T08:39:10.655Z caller=nflog.go:540 component=nflog msg="gossiping new entry" entry="entry:<group_key:\"{}:{alertname=\\\"DemoAlert\\\"}\" receiver:<group_name:\"web.hook\" integration:\"webhook\" > timestamp:<seconds:1610008750 nanos:594514657 > firing_alerts:3742573726221535510 > expires_at:<seconds:1610440750 nanos:594514657 > "
level=debug ts=2021-01-07T08:39:10.744Z caller=nflog.go:540 component=nflog msg="gossiping new entry" entry="entry:<group_key:\"{}:{alertname=\\\"DemoAlert\\\"}\" receiver:<group_name:\"web.hook\" integration:\"webhook\" > timestamp:<seconds:1610008750 nanos:618452284 > firing_alerts:3742573726221535510 > expires_at:<seconds:1610440750 nanos:618452284 > "
level=debug ts=2021-01-07T08:39:25.945Z caller=nflog.go:540 component=nflog msg="gossiping new entry" entry="entry:<group_key:\"{}:{alertname=\\\"DemoAlert\\\"}\" receiver:<group_name:\"web.hook\" integration:\"webhook\" > timestamp:<seconds:1610008765 nanos:822504049 > resolved_alerts:3742573726221535510 > expires_at:<seconds:1610440765 nanos:822504049 > "

node '<IP_ADDRESS>:9090' = n2
level=debug ts=2021-01-07T08:35:51.885Z caller=main.go:355 externalURL=http://n2:9093
level=info ts=2021-01-07T08:35:51.885Z caller=coordinator.go:119 component=configuration msg="Loading configuration file" file=./alertmanager-0.21.0.linux-amd64/alertmanager.yml
level=info ts=2021-01-07T08:35:51.885Z caller=coordinator.go:131 component=configuration msg="Completed loading of configuration file" file=./alertmanager-0.21.0.linux-amd64/alertmanager.yml
level=debug ts=2021-01-07T08:35:51.886Z caller=main.go:465 routePrefix=/
level=info ts=2021-01-07T08:35:51.886Z caller=main.go:485 msg=Listening address=:9093
level=info ts=2021-01-07T08:35:53.865Z caller=cluster.go:648 component=cluster msg="gossip not settled" polls=0 before=0 now=3 elapsed=2.000233918s
level=debug ts=2021-01-07T08:35:55.866Z caller=cluster.go:645 component=cluster msg="gossip looks settled" elapsed=4.000945507s
level=debug ts=2021-01-07T08:35:57.866Z caller=cluster.go:645 component=cluster msg="gossip looks settled" elapsed=6.001335775s
level=debug ts=2021-01-07T08:35:59.866Z caller=cluster.go:645 component=cluster msg="gossip looks settled" elapsed=8.001837012s
level=info ts=2021-01-07T08:36:01.869Z caller=cluster.go:640 component=cluster msg="gossip settled; proceeding" elapsed=10.004591595s
level=debug ts=2021-01-07T08:36:53.607Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:36:53 [DEBUG] memberlist: Initiating push/pull sync with: 01EVDY7T8KDZ7SG98H27F3EG9Y <IP_ADDRESS>:9094\n"
level=debug ts=2021-01-07T08:37:02.057Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:37:02 [DEBUG] memberlist: Stream connection from=<IP_ADDRESS>:59306\n"
level=debug ts=2021-01-07T08:37:43.185Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:37:43 [DEBUG] memberlist: Stream connection from=<IP_ADDRESS>:55954\n"
level=debug ts=2021-01-07T08:37:53.612Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:37:53 [DEBUG] memberlist: Initiating push/pull sync with: 01EVDY6D0YSSM8DM6G8Z8DMF95 <IP_ADDRESS>:9094\n"
level=debug ts=2021-01-07T08:38:00.039Z caller=dispatch.go:138 component=dispatcher msg="Received alert" alert=DemoAlert[8a07086][active]
level=debug ts=2021-01-07T08:38:00.042Z caller=dispatch.go:138 component=dispatcher msg="Received alert" alert=DemoAlert[8a07086][active]
level=debug ts=2021-01-07T08:38:02.061Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:38:02 [DEBUG] memberlist: Stream connection from=<IP_ADDRESS>:59318\n"
level=debug ts=2021-01-07T08:38:10.040Z caller=dispatch.go:473 component=dispatcher aggrGroup="{}:{alertname=\"DemoAlert\"}" msg=flushing alerts=[DemoAlert[8a07086][active]]
level=debug ts=2021-01-07T08:38:11.229Z caller=nflog.go:540 component=nflog msg="gossiping new entry" entry="entry:<group_key:\"{}:{alertname=\\\"DemoAlert\\\"}\" receiver:<group_name:\"web.hook\" integration:\"webhook\" > timestamp:<seconds:1610008691 nanos:71839256 > firing_alerts:3742573726221535510 > expires_at:<seconds:1610440691 nanos:71839256 > "
level=debug ts=2021-01-07T08:38:40.041Z caller=dispatch.go:473 component=dispatcher aggrGroup="{}:{alertname=\"DemoAlert\"}" msg=flushing alerts=[DemoAlert[8a07086][active]]
level=debug ts=2021-01-07T08:38:53.616Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:38:53 [DEBUG] memberlist: Initiating push/pull sync with: 01EVDY7T8KDZ7SG98H27F3EG9Y <IP_ADDRESS>:9094\n"
level=debug ts=2021-01-07T08:39:00.038Z caller=dispatch.go:138 component=dispatcher msg="Received alert" alert=DemoAlert[8a07086][resolved]
level=debug ts=2021-01-07T08:39:00.227Z caller=nflog.go:540 component=nflog msg="gossiping new entry" entry="entry:<group_key:\"{}:{alertname=\\\"DemoAlert\\\"}\" receiver:<group_name:\"web.hook\" integration:\"webhook\" > timestamp:<seconds:1610008740 nanos:188592422 > resolved_alerts:3742573726221535510 > expires_at:<seconds:1610440740 nanos:188592422 > "
level=debug ts=2021-01-07T08:39:10.594Z caller=notify.go:685 component=dispatcher receiver=web.hook integration=webhook[0] msg="Notify success" attempts=1
level=debug ts=2021-01-07T08:39:10.594Z caller=dispatch.go:473 component=dispatcher aggrGroup="{}:{alertname=\"DemoAlert\"}" msg=flushing alerts=[DemoAlert[8a07086][resolved]]
level=debug ts=2021-01-07T08:39:10.747Z caller=nflog.go:540 component=nflog msg="gossiping new entry" entry="entry:<group_key:\"{}:{alertname=\\\"DemoAlert\\\"}\" receiver:<group_name:\"web.hook\" integration:\"webhook\" > timestamp:<seconds:1610008750 nanos:618452284 > firing_alerts:3742573726221535510 > expires_at:<seconds:1610440750 nanos:618452284 > "
level=debug ts=2021-01-07T08:39:25.948Z caller=nflog.go:540 component=nflog msg="gossiping new entry" entry="entry:<group_key:\"{}:{alertname=\\\"DemoAlert\\\"}\" receiver:<group_name:\"web.hook\" integration:\"webhook\" > timestamp:<seconds:1610008765 nanos:822504049 > resolved_alerts:3742573726221535510 > expires_at:<seconds:1610440765 nanos:822504049 > "
level=debug ts=2021-01-07T08:39:43.192Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:39:43 [DEBUG] memberlist: Stream connection from=<IP_ADDRESS>:55972\n"
level=debug ts=2021-01-07T08:39:53.619Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:39:53 [DEBUG] memberlist: Initiating push/pull sync with: 01EVDY6D0YSSM8DM6G8Z8DMF95 <IP_ADDRESS>:9094\n"
level=debug ts=2021-01-07T08:40:00.042Z caller=dispatch.go:138 component=dispatcher msg="Received alert" alert=DemoAlert[8a07086][resolved]
level=debug ts=2021-01-07T08:40:00.042Z caller=dispatch.go:473 component=dispatcher aggrGroup="{}:{alertname=\"DemoAlert\"}" msg=flushing alerts=[DemoAlert[8a07086][resolved]]
level=debug ts=2021-01-07T08:40:53.623Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:40:53 [DEBUG] memberlist: Initiating push/pull sync with: 01EVDY6D0YSSM8DM6G8Z8DMF95 <IP_ADDRESS>:9094\n"
level=debug ts=2021-01-07T08:41:00.048Z caller=dispatch.go:138 component=dispatcher msg="Received alert" alert=DemoAlert[8a07086][resolved]
level=debug ts=2021-01-07T08:41:00.048Z caller=dispatch.go:473 component=dispatcher aggrGroup="{}:{alertname=\"DemoAlert\"}" msg=flushing alerts=[DemoAlert[8a07086][resolved]]
level=debug ts=2021-01-07T08:41:43.198Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:41:43 [DEBUG] memberlist: Stream connection from=<IP_ADDRESS>:55976\n"
level=debug ts=2021-01-07T08:41:53.628Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:41:53 [DEBUG] memberlist: Initiating push/pull sync with: 01EVDY6D0YSSM8DM6G8Z8DMF95 <IP_ADDRESS>:9094\n"
level=debug ts=2021-01-07T08:42:00.040Z caller=dispatch.go:138 component=dispatcher msg="Received alert" alert=DemoAlert[8a07086][resolved]
level=debug ts=2021-01-07T08:42:00.041Z caller=dispatch.go:473 component=dispatcher aggrGroup="{}:{alertname=\"DemoAlert\"}" msg=flushing alerts=[DemoAlert[8a07086][resolved]]

Alertmanager node '<IP_ADDRESS>:9090' = n3
vagrant@n1:~$ tail -f alertmanager.log
level=debug ts=2021-01-07T08:35:43.180Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:35:43 [DEBUG] memberlist: Stream connection from=<IP_ADDRESS>:56578\n"
level=debug ts=2021-01-07T08:35:45.350Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:35:45 [DEBUG] memberlist: Failed to join <IP_ADDRESS>: dial tcp <IP_ADDRESS>:9094: connect: connection refused\n"
level=debug ts=2021-01-07T08:35:45.351Z caller=cluster.go:408 component=cluster msg=reconnect result=failure peer= addr=<IP_ADDRESS>:9094 err="1 error occurred:\n\t* Failed to join <IP_ADDRESS>: dial tcp <IP_ADDRESS>:9094: connect: connection refused\n\n"
level=debug ts=2021-01-07T08:35:50.354Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:35:50 [DEBUG] memberlist: Failed to join <IP_ADDRESS>: dial tcp <IP_ADDRESS>:9094: connect: connection refused\n"
level=warn ts=2021-01-07T08:35:50.354Z caller=cluster.go:438 component=cluster msg=refresh result=failure addr=<IP_ADDRESS>:9094 err="1 error occurred:\n\t* Failed to join <IP_ADDRESS>: dial tcp <IP_ADDRESS>:9094: connect: connection refused\n\n"
level=debug ts=2021-01-07T08:35:51.860Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:35:51 [DEBUG] memberlist: Stream connection from=<IP_ADDRESS>:42642\n"
level=debug ts=2021-01-07T08:35:51.860Z caller=delegate.go:230 component=cluster received=NotifyJoin node=01EVDZSRDH74YHZ0RPDC3TRE38 addr=<IP_ADDRESS>:9094
level=debug ts=2021-01-07T08:35:51.860Z caller=cluster.go:470 component=cluster msg="peer rejoined" peer=01EVDZSRDH74YHZ0RPDC3TRE38
level=debug ts=2021-01-07T08:36:02.051Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:36:02 [DEBUG] memberlist: Initiating push/pull sync with: 01EVDY6D0YSSM8DM6G8Z8DMF95 <IP_ADDRESS>:9094\n"
level=debug ts=2021-01-07T08:36:43.183Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:36:43 [DEBUG] memberlist: Stream connection from=<IP_ADDRESS>:56588\n"
level=debug ts=2021-01-07T08:36:53.608Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:36:53 [DEBUG] memberlist: Stream connection from=<IP_ADDRESS>:42648\n"
level=debug ts=2021-01-07T08:37:02.057Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:37:02 [DEBUG] memberlist: Initiating push/pull sync with: 01EVDZSRDH74YHZ0RPDC3TRE38 <IP_ADDRESS>:9094\n"
level=debug ts=2021-01-07T08:38:00.038Z caller=dispatch.go:138 component=dispatcher msg="Received alert" alert=DemoAlert[8a07086][active]
level=debug ts=2021-01-07T08:38:00.042Z caller=dispatch.go:138 component=dispatcher msg="Received alert" alert=DemoAlert[8a07086][active]
level=debug ts=2021-01-07T08:38:02.061Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:38:02 [DEBUG] memberlist: Initiating push/pull sync with: 01EVDZSRDH74YHZ0RPDC3TRE38 <IP_ADDRESS>:9094\n"
level=debug ts=2021-01-07T08:38:10.038Z caller=dispatch.go:473 component=dispatcher aggrGroup="{}:{alertname=\"DemoAlert\"}" msg=flushing alerts=[DemoAlert[8a07086][active]]
level=debug ts=2021-01-07T08:38:11.230Z caller=nflog.go:540 component=nflog msg="gossiping new entry" entry="entry:<group_key:\"{}:{alertname=\\\"DemoAlert\\\"}\" receiver:<group_name:\"web.hook\" integration:\"webhook\" > timestamp:<seconds:1610008691 nanos:71839256 > firing_alerts:3742573726221535510 > expires_at:<seconds:1610440691 nanos:71839256 > "
level=debug ts=2021-01-07T08:38:25.039Z caller=dispatch.go:473 component=dispatcher aggrGroup="{}:{alertname=\"DemoAlert\"}" msg=flushing alerts=[DemoAlert[8a07086][active]]
level=debug ts=2021-01-07T08:38:35.348Z caller=silence.go:350 component=silences msg="Running maintenance"
level=debug ts=2021-01-07T08:38:35.350Z caller=nflog.go:336 component=nflog msg="Running maintenance"
level=debug ts=2021-01-07T08:38:35.353Z caller=silence.go:352 component=silences msg="Maintenance done" duration=4.748617ms size=226
level=debug ts=2021-01-07T08:38:35.353Z caller=nflog.go:338 component=nflog msg="Maintenance done" duration=3.004791ms size=280
level=debug ts=2021-01-07T08:38:40.041Z caller=dispatch.go:473 component=dispatcher aggrGroup="{}:{alertname=\"DemoAlert\"}" msg=flushing alerts=[DemoAlert[8a07086][active]]
level=debug ts=2021-01-07T08:38:43.188Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:38:43 [DEBUG] memberlist: Stream connection from=<IP_ADDRESS>:56606\n"
level=debug ts=2021-01-07T08:38:53.617Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:38:53 [DEBUG] memberlist: Stream connection from=<IP_ADDRESS>:42656\n"
level=debug ts=2021-01-07T08:38:55.045Z caller=dispatch.go:473 component=dispatcher aggrGroup="{}:{alertname=\"DemoAlert\"}" msg=flushing alerts=[DemoAlert[8a07086][active]]
level=debug ts=2021-01-07T08:39:00.038Z caller=dispatch.go:138 component=dispatcher msg="Received alert" alert=DemoAlert[8a07086][resolved]
level=debug ts=2021-01-07T08:39:00.227Z caller=nflog.go:540 component=nflog msg="gossiping new entry" entry="entry:<group_key:\"{}:{alertname=\\\"DemoAlert\\\"}\" receiver:<group_name:\"web.hook\" integration:\"webhook\" > timestamp:<seconds:1610008740 nanos:188592422 > resolved_alerts:3742573726221535510 > expires_at:<seconds:1610440740 nanos:188592422 > "
level=debug ts=2021-01-07T08:39:02.071Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:39:02 [DEBUG] memberlist: Initiating push/pull sync with: 01EVDY6D0YSSM8DM6G8Z8DMF95 <IP_ADDRESS>:9094\n"
level=debug ts=2021-01-07T08:39:10.618Z caller=notify.go:685 component=dispatcher receiver=web.hook integration=webhook[0] msg="Notify success" attempts=1
level=debug ts=2021-01-07T08:39:10.618Z caller=dispatch.go:473 component=dispatcher aggrGroup="{}:{alertname=\"DemoAlert\"}" msg=flushing alerts=[DemoAlert[8a07086][resolved]]
level=debug ts=2021-01-07T08:39:25.822Z caller=notify.go:685 component=dispatcher receiver=web.hook integration=webhook[0] msg="Notify success" attempts=1
level=debug ts=2021-01-07T08:40:00.042Z caller=dispatch.go:138 component=dispatcher msg="Received alert" alert=DemoAlert[8a07086][resolved]
level=debug ts=2021-01-07T08:40:00.044Z caller=dispatch.go:473 component=dispatcher aggrGroup="{}:{alertname=\"DemoAlert\"}" msg=flushing alerts=[DemoAlert[8a07086][resolved]]
level=debug ts=2021-01-07T08:40:02.079Z caller=cluster.go:306 component=cluster memberlist="2021/01/07 08:40:02 [DEBUG] memberlist: Initiating push/pull sync with: 01EVDY6D0YSSM8DM6G8Z8DMF95 <IP_ADDRESS>:9094\n"

WebHooksEvents from Pipedream
Alert Notification 2021-01-07T09:38:11.059+01:00 from "http://n3:9093"

{
  "method": "POST",
  "path": "/",
  "query": {},
  "headers": {
    "x-forwarded-for": "<IP_ADDRESS>",
    "x-forwarded-proto": "https",
    "x-forwarded-port": "443",
    "host": "a94434b3d427cb85c35eb4ad0be45e6d.m.pipedream.net",
    "x-amzn-trace-id": "Root=1-5ff6c872-7587b24945882b802dcbf45c",
    "content-length": "670",
    "content-type": "application/json",
    "user-agent": "Alertmanager/0.21.0"
  },
  "bodyRaw": "{\"receiver\":\"web\\\\.hook\",\"status\":\"firing\",\"alerts\":[{\"status\":\"firing\",\"labels\":{\"alertname\":\"DemoAlert\",\"server\":\"ni3\",\"severity\":\"critical\"},\"annotations\":{\"summary\":\"This is a demo\"},\"startsAt\":\"2021-01-07T08:38:00.032813093Z\",\"endsAt\":\"0001-01-01T00:00:00Z\",\"generatorURL\":\"http://n3:9090/graph?g0.expr=sum%28prometheus_build_info%29+%3C+3\\u0026g0.tab=1\",\"fingerprint\":\"8a07086b74f3ba78\"}],\"groupLabels\":{\"alertname\":\"DemoAlert\"},\"commonLabels\":{\"alertname\":\"DemoAlert\",\"server\":\"ni3\",\"severity\":\"critical\"},\"commonAnnotations\":{\"summary\":\"This is a demo\"},\"externalURL\":\"http://n3:9093\",\"version\":\"4\",\"groupKey\":\"{}:{alertname=\\\"DemoAlert\\\"}\",\"truncatedAlerts\":0}\n",
  "body": {
    "receiver": "web\\.hook",
    "status": "firing",
    "alerts": [
      {
        "status": "firing",
        "labels": {
          "alertname": "DemoAlert",
          "server": "ni3",
          "severity": "critical"
        },
        "annotations": {
          "summary": "This is a demo"
        },
        "startsAt": "2021-01-07T08:38:00.032813093Z",
        "endsAt": "0001-01-01T00:00:00Z",
        "generatorURL": "http://n3:9090/graph?g0.expr=sum%28prometheus_build_info%29+%3C+3&g0.tab=1",
        "fingerprint": "8a07086b74f3ba78"
      }
    ],
    "groupLabels": {
      "alertname": "DemoAlert"
    },
    "commonLabels": {
      "alertname": "DemoAlert",
      "server": "ni3",
      "severity": "critical"
    },
    "commonAnnotations": {
      "summary": "This is a demo"
    },
    "externalURL": "http://n3:9093",
    "version": "4",
    "groupKey": "{}:{alertname=\"DemoAlert\"}",
    "truncatedAlerts": 0
  }
}

Resolved Notification 2021-01-07T09:39:00.175+01:00 from "http://n3:9093"
{
  "method": "POST",
  "path": "/",
  "query": {},
  "headers": {
    "x-forwarded-for": "<IP_ADDRESS>",
    "x-forwarded-proto": "https",
    "x-forwarded-port": "443",
    "host": "a94434b3d427cb85c35eb4ad0be45e6d.m.pipedream.net",
    "x-amzn-trace-id": "Root=1-5ff6c8a4-15435eaa45d9ca1179d08f32",
    "content-length": "684",
    "content-type": "application/json",
    "user-agent": "Alertmanager/0.21.0"
  },
  "bodyRaw": "{\"receiver\":\"web\\\\.hook\",\"status\":\"resolved\",\"alerts\":[{\"status\":\"resolved\",\"labels\":{\"alertname\":\"DemoAlert\",\"server\":\"ni3\",\"severity\":\"critical\"},\"annotations\":{\"summary\":\"This is a demo\"},\"startsAt\":\"2021-01-07T08:38:00.032813093Z\",\"endsAt\":\"2021-01-07T08:39:00.032813093Z\",\"generatorURL\":\"http://n3:9090/graph?g0.expr=sum%28prometheus_build_info%29+%3C+3\\u0026g0.tab=1\",\"fingerprint\":\"8a07086b74f3ba78\"}],\"groupLabels\":{\"alertname\":\"DemoAlert\"},\"commonLabels\":{\"alertname\":\"DemoAlert\",\"server\":\"ni3\",\"severity\":\"critical\"},\"commonAnnotations\":{\"summary\":\"This is a demo\"},\"externalURL\":\"http://n3:9093\",\"version\":\"4\",\"groupKey\":\"{}:{alertname=\\\"DemoAlert\\\"}\",\"truncatedAlerts\":0}\n",
  "body": {
    "receiver": "web\\.hook",
    "status": "resolved",
    "alerts": [
      {
        "status": "resolved",
        "labels": {
          "alertname": "DemoAlert",
          "server": "ni3",
          "severity": "critical"
        },
        "annotations": {
          "summary": "This is a demo"
        },
        "startsAt": "2021-01-07T08:38:00.032813093Z",
        "endsAt": "2021-01-07T08:39:00.032813093Z",
        "generatorURL": "http://n3:9090/graph?g0.expr=sum%28prometheus_build_info%29+%3C+3&g0.tab=1",
        "fingerprint": "8a07086b74f3ba78"
      }
    ],
    "groupLabels": {
      "alertname": "DemoAlert"
    },
    "commonLabels": {
      "alertname": "DemoAlert",
      "server": "ni3",
      "severity": "critical"
    },
    "commonAnnotations": {
      "summary": "This is a demo"
    },
    "externalURL": "http://n3:9093",
    "version": "4",
    "groupKey": "{}:{alertname=\"DemoAlert\"}",
    "truncatedAlerts": 0
  }
}

Alert Notification 2021-01-07T09:39:10.572+01:00 from "http://n2:9093"
{
  "method": "POST",
  "path": "/",
  "query": {},
  "headers": {
    "x-forwarded-for": "<IP_ADDRESS>",
    "x-forwarded-proto": "https",
    "x-forwarded-port": "443",
    "host": "a94434b3d427cb85c35eb4ad0be45e6d.m.pipedream.net",
    "x-amzn-trace-id": "Root=1-5ff6c8ae-55d448e5443cb64b4d61e6f5",
    "content-length": "670",
    "content-type": "application/json",
    "user-agent": "Alertmanager/0.21.0"
  },
  "bodyRaw": "{\"receiver\":\"web\\\\.hook\",\"status\":\"firing\",\"alerts\":[{\"status\":\"firing\",\"labels\":{\"alertname\":\"DemoAlert\",\"server\":\"ni3\",\"severity\":\"critical\"},\"annotations\":{\"summary\":\"This is a demo\"},\"startsAt\":\"2021-01-07T08:38:00.032813093Z\",\"endsAt\":\"0001-01-01T00:00:00Z\",\"generatorURL\":\"http://n3:9090/graph?g0.expr=sum%28prometheus_build_info%29+%3C+3\\u0026g0.tab=1\",\"fingerprint\":\"8a07086b74f3ba78\"}],\"groupLabels\":{\"alertname\":\"DemoAlert\"},\"commonLabels\":{\"alertname\":\"DemoAlert\",\"server\":\"ni3\",\"severity\":\"critical\"},\"commonAnnotations\":{\"summary\":\"This is a demo\"},\"externalURL\":\"http://n2:9093\",\"version\":\"4\",\"groupKey\":\"{}:{alertname=\\\"DemoAlert\\\"}\",\"truncatedAlerts\":0}\n",
  "body": {
    "receiver": "web\\.hook",
    "status": "firing",
    "alerts": [
      {
        "status": "firing",
        "labels": {
          "alertname": "DemoAlert",
          "server": "ni3",
          "severity": "critical"
        },
        "annotations": {
          "summary": "This is a demo"
        },
        "startsAt": "2021-01-07T08:38:00.032813093Z",
        "endsAt": "0001-01-01T00:00:00Z",
        "generatorURL": "http://n3:9090/graph?g0.expr=sum%28prometheus_build_info%29+%3C+3&g0.tab=1",
        "fingerprint": "8a07086b74f3ba78"
      }
    ],
    "groupLabels": {
      "alertname": "DemoAlert"
    },
    "commonLabels": {
      "alertname": "DemoAlert",
      "server": "ni3",
      "severity": "critical"
    },
    "commonAnnotations": {
      "summary": "This is a demo"
    },
    "externalURL": "http://n2:9093",
    "version": "4",
    "groupKey": "{}:{alertname=\"DemoAlert\"}",
    "truncatedAlerts": 0
  }
}

Alert Notification 2021-01-07T09:39:10.627+01:00 from "http://n1:9093"
{
  "method": "POST",
  "path": "/",
  "query": {},
  "headers": {
    "x-forwarded-for": "<IP_ADDRESS>",
    "x-forwarded-proto": "https",
    "x-forwarded-port": "443",
    "host": "a94434b3d427cb85c35eb4ad0be45e6d.m.pipedream.net",
    "x-amzn-trace-id": "Root=1-5ff6c8ae-738a893c0e0f9723325be3d4",
    "content-length": "670",
    "user-agent": "Alertmanager/0.21.0",
    "content-type": "application/json"
  },
  "bodyRaw": "{\"receiver\":\"web\\\\.hook\",\"status\":\"firing\",\"alerts\":[{\"status\":\"firing\",\"labels\":{\"alertname\":\"DemoAlert\",\"server\":\"ni3\",\"severity\":\"critical\"},\"annotations\":{\"summary\":\"This is a demo\"},\"startsAt\":\"2021-01-07T08:38:00.032813093Z\",\"endsAt\":\"0001-01-01T00:00:00Z\",\"generatorURL\":\"http://n3:9090/graph?g0.expr=sum%28prometheus_build_info%29+%3C+3\\u0026g0.tab=1\",\"fingerprint\":\"8a07086b74f3ba78\"}],\"groupLabels\":{\"alertname\":\"DemoAlert\"},\"commonLabels\":{\"alertname\":\"DemoAlert\",\"server\":\"ni3\",\"severity\":\"critical\"},\"commonAnnotations\":{\"summary\":\"This is a demo\"},\"externalURL\":\"http://n1:9093\",\"version\":\"4\",\"groupKey\":\"{}:{alertname=\\\"DemoAlert\\\"}\",\"truncatedAlerts\":0}\n",
  "body": {
    "receiver": "web\\.hook",
    "status": "firing",
    "alerts": [
      {
        "status": "firing",
        "labels": {
          "alertname": "DemoAlert",
          "server": "ni3",
          "severity": "critical"
        },
        "annotations": {
          "summary": "This is a demo"
        },
        "startsAt": "2021-01-07T08:38:00.032813093Z",
        "endsAt": "0001-01-01T00:00:00Z",
        "generatorURL": "http://n3:9090/graph?g0.expr=sum%28prometheus_build_info%29+%3C+3&g0.tab=1",
        "fingerprint": "8a07086b74f3ba78"
      }
    ],
    "groupLabels": {
      "alertname": "DemoAlert"
    },
    "commonLabels": {
      "alertname": "DemoAlert",
      "server": "ni3",
      "severity": "critical"
    },
    "commonAnnotations": {
      "summary": "This is a demo"
    },
    "externalURL": "http://n1:9093",
    "version": "4",
    "groupKey": "{}:{alertname=\"DemoAlert\"}",
    "truncatedAlerts": 0
  }
}

Resolve Notification 2021-01-07T09:39:25.801+01:00 from "http://n1:9093"
{
  "method": "POST",
  "path": "/",
  "query": {},
  "headers": {
    "x-forwarded-for": "<IP_ADDRESS>",
    "x-forwarded-proto": "https",
    "x-forwarded-port": "443",
    "host": "a94434b3d427cb85c35eb4ad0be45e6d.m.pipedream.net",
    "x-amzn-trace-id": "Root=1-5ff6c8bd-640673fd07455c703cc94875",
    "content-length": "684",
    "content-type": "application/json",
    "user-agent": "Alertmanager/0.21.0"
  },
  "bodyRaw": "{\"receiver\":\"web\\\\.hook\",\"status\":\"resolved\",\"alerts\":[{\"status\":\"resolved\",\"labels\":{\"alertname\":\"DemoAlert\",\"server\":\"ni3\",\"severity\":\"critical\"},\"annotations\":{\"summary\":\"This is a demo\"},\"startsAt\":\"2021-01-07T08:38:00.032813093Z\",\"endsAt\":\"2021-01-07T08:39:00.032813093Z\",\"generatorURL\":\"http://n3:9090/graph?g0.expr=sum%28prometheus_build_info%29+%3C+3\\u0026g0.tab=1\",\"fingerprint\":\"8a07086b74f3ba78\"}],\"groupLabels\":{\"alertname\":\"DemoAlert\"},\"commonLabels\":{\"alertname\":\"DemoAlert\",\"server\":\"ni3\",\"severity\":\"critical\"},\"commonAnnotations\":{\"summary\":\"This is a demo\"},\"externalURL\":\"http://n1:9093\",\"version\":\"4\",\"groupKey\":\"{}:{alertname=\\\"DemoAlert\\\"}\",\"truncatedAlerts\":0}\n",
  "body": {
    "receiver": "web\\.hook",
    "status": "resolved",
    "alerts": [
      {
        "status": "resolved",
        "labels": {
          "alertname": "DemoAlert",
          "server": "ni3",
          "severity": "critical"
        },
        "annotations": {
          "summary": "This is a demo"
        },
        "startsAt": "2021-01-07T08:38:00.032813093Z",
        "endsAt": "2021-01-07T08:39:00.032813093Z",
        "generatorURL": "http://n3:9090/graph?g0.expr=sum%28prometheus_build_info%29+%3C+3&g0.tab=1",
        "fingerprint": "8a07086b74f3ba78"
      }
    ],
    "groupLabels": {
      "alertname": "DemoAlert"
    },
    "commonLabels": {
      "alertname": "DemoAlert",
      "server": "ni3",
      "severity": "critical"
    },
    "commonAnnotations": {
      "summary": "This is a demo"
    },
    "externalURL": "http://n1:9093",
    "version": "4",
    "groupKey": "{}:{alertname=\"DemoAlert\"}",
    "truncatedAlerts": 0
  }
}

This is something that I have experienced before. I think it has to do with the ratio between group_wait and group_interval configured. Also external factors like network latency between your alertmanagers can play a role.
I had some good experience with setting the group_interval to at least 4 times the value of group_wait.
Let me know if that solves those immediate issues and if you still experience resends I would suggest to raise it even further. Meanwhile I will have a try to understand the related code sections and see if there is more that can be done.

This is something that I have experienced before. I think it has to do with the ratio between group_wait and group_interval configured. Also external factors like network latency between your alertmanagers can play a role.
I had some good experience with setting the group_interval to at least 4 times the value of group_wait.
Let me know if that solves those immediate issues and if you still experience resends I would suggest to raise it even further. Meanwhile I will have a try to understand the related code sections and see if there is more that can be done.

I had some good experience with setting the group_interval to at least 4 times the value of group_wait."

Thanks. That solves the problem. Now, I get the alert and the resolve notification only once.
The Alertmanager config is now looking like that:
...
route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 40s
  repeat_interval: 1h
  receiver: 'web.hook'
...

I had some good experience with setting the group_interval to at least 4 times the value of group_wait."

Thanks. That solves the problem. Now, I get the alert and the resolve notification only once.
The Alertmanager config is now looking like that:
...
route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 40s
  repeat_interval: 1h
  receiver: 'web.hook'
...

Thanks for the detailed report. Yes having short group_interval values is prone to notifications being resent after they resolve. This is because of how the clustering works: every Alertmanager instance will delay the group processing based on its position in the cluster. In practice, the first instance will start immediatly, the second instance will wait 115 seconds, the third instance will wait 215 seconds, and so on.
You can see it from the n3 logs:
level=debug ts=2021-01-07T08:38:55.045Z caller=dispatch.go:473 component=dispatcher aggrGroup="{}:{alertname=\"DemoAlert\"}" msg=flushing alerts=[DemoAlert[8a07086][active]]
level=debug ts=2021-01-07T08:39:00.038Z caller=dispatch.go:138 component=dispatcher msg="Received alert" alert=DemoAlert[8a07086][resolved]
level=debug ts=2021-01-07T08:39:00.227Z caller=nflog.go:540 component=nflog msg="gossiping new entry" entry="entry:<group_key:\"{}:{alertname=\\\"DemoAlert\\\"}\" receiver:<group_name:\"web.hook\" integration:\"webhook\" > timestamp:<seconds:1610008740 nanos:188592422 > resolved_alerts:3742573726221535510 > expires_at:<seconds:1610440740 nanos:188592422 > "
level=debug ts=2021-01-07T08:39:10.618Z caller=notify.go:685 component=dispatcher receiver=web.hook integration=webhook[0] msg="Notify success" attempts=1

At 08:38:55045 Alertmanager flushes the aggregation group while the alert is still active.
At 08:39:00.038 it gets the resolved alert.
At 08:39:00.227 it gets the log from the other Alertmanager instance that already sent the resolved notification.
At 08:39:10.618 it sends the firing notification that was initiated at 08:38:55045.

The 15 seconds value comes from the --cluster.peer-timeout argument and you could tweak it but at the risk of getting even more duplicated notifications if your receiver or the replication of notificaiton logs between instances lags behind.
I keep the issue open, it's something that Alertmanager should at least be able to surface to the users.

Thanks for the detailed report. Yes having short group_interval values is prone to notifications being resent after they resolve. This is because of how the clustering works: every Alertmanager instance will delay the group processing based on its position in the cluster. In practice, the first instance will start immediatly, the second instance will wait 115 seconds, the third instance will wait 215 seconds, and so on.
You can see it from the n3 logs:
level=debug ts=2021-01-07T08:38:55.045Z caller=dispatch.go:473 component=dispatcher aggrGroup="{}:{alertname=\"DemoAlert\"}" msg=flushing alerts=[DemoAlert[8a07086][active]]
level=debug ts=2021-01-07T08:39:00.038Z caller=dispatch.go:138 component=dispatcher msg="Received alert" alert=DemoAlert[8a07086][resolved]
level=debug ts=2021-01-07T08:39:00.227Z caller=nflog.go:540 component=nflog msg="gossiping new entry" entry="entry:<group_key:\"{}:{alertname=\\\"DemoAlert\\\"}\" receiver:<group_name:\"web.hook\" integration:\"webhook\" > timestamp:<seconds:1610008740 nanos:188592422 > resolved_alerts:3742573726221535510 > expires_at:<seconds:1610440740 nanos:188592422 > "
level=debug ts=2021-01-07T08:39:10.618Z caller=notify.go:685 component=dispatcher receiver=web.hook integration=webhook[0] msg="Notify success" attempts=1

At 08:38:55045 Alertmanager flushes the aggregation group while the alert is still active.
At 08:39:00.038 it gets the resolved alert.
At 08:39:00.227 it gets the log from the other Alertmanager instance that already sent the resolved notification.
At 08:39:10.618 it sends the firing notification that was initiated at 08:38:55045.

The 15 seconds value comes from the --cluster.peer-timeout argument and you could tweak it but at the risk of getting even more duplicated notifications if your receiver or the replication of notificaiton logs between instances lags behind.
I keep the issue open, it's something that Alertmanager should at least be able to surface to the users.

@simonpasquier that makes a lot of sense. I spent quite a bit of time understanding what's going on and this is roughly matches with the understanding I got.
I was thinking one possible way of avoiding this "peer-timeout delayed notifications" to generate duplicates would be if we would keep look into more nflog.Entries instead of only the last one per groupKey (https://github.com/prometheus/alertmanager/blob/e6824a31100bd59308ad769a71371274455c0914/nflog/nflog.go#L450
), as part of the DedupStage notification step.
I think if we would consider looking at the latest nflog.Entries per alertHash per groupKey, we should be able to compare if an alert has been resolved in the meantime.
Do you think this could be a sensible approach?

@simonpasquier that makes a lot of sense. I spent quite a bit of time understanding what's going on and this is roughly matches with the understanding I got.
I was thinking one possible way of avoiding this "peer-timeout delayed notifications" to generate duplicates would be if we would keep look into more nflog.Entries instead of only the last one per groupKey (https://github.com/prometheus/alertmanager/blob/e6824a31100bd59308ad769a71371274455c0914/nflog/nflog.go#L450
), as part of the DedupStage notification step.
I think if we would consider looking at the latest nflog.Entries per alertHash per groupKey, we should be able to compare if an alert has been resolved in the meantime.
Do you think this could be a sensible approach?

I would need to put more thoughts into this but the untangible principle is that the recipient is guaranteed to get the eventual state of the notification. To that respect, the current trade-off is indeed that the remote system can receive conflicting notifications sometimes.

I would need to put more thoughts into this but the untangible principle is that the recipient is guaranteed to get the eventual state of the notification. To that respect, the current trade-off is indeed that the remote system can receive conflicting notifications sometimes.


Set stack to heroku-20

Description
Set stack to heroku-20
Fixes # (issue)
Should resolve #256
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Instructions
Create PR going to develop.

As demonstrated in the build above, this PR should fix the issue.


[QUESTION]: Update documenation PowerFlex CSI driver support support for EKS Anywhere to YES

How can the Team help you today?
Dell APJ Presales team has installed and successfully tested PowerFlex 2.6 with EKS Anywhere with multiple variations and configurations. and will validate that it can be deployed with the latest version of CSM as well.
Details here:
https://ambar-thecloudgarage.medium.com/eks-anywhere-on-bare-metal-with-dell-technologies-and-metalsoft-c91f78020dbc
Can the documentation then be updated in the Community Qualified Platform section?
https://dell.github.io/csm-docs/docs/csidriver/#community-qualified-platforms

Updated via https://github.com/dell/csm-docs/pull/1025