Add a dry run mode for the preprocess

As distribution rules involve pattern matching, it is easy to make a mistake and, in the current workflow, difficult to validate.
I propose to add a -dry_run flag to preprocess.lua to only prepare the preprocessor and log matched files and weights. For example:
th preprocess.lua -gsample_dist rules.txt -gsample 100000 -train_dir data/ -dry_run

This will allow quick validation and testing of the distribution rules files.

Codecov Report

Merging #392 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #392      +/-   ##
==========================================
+ Coverage   69.59%   69.59%   +<.01%
==========================================
  Files          74       74
  Lines        6285     6286       +1
==========================================
+ Hits         4374     4375       +1
  Misses       1911     1911

Impacted Files
Coverage Δ

onmt/data/Preprocessor.lua
92.92% <100%> (+0.01%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5b9b886...8a46a18. Read the comment docs.


Update copyright year

I'm just updating the footer year. Thanks for this great resource!

Danke @stefanjudis!


Example showing processing zipped xls files

I'm trying to construct an example for processing zipped xls.
Downloader seems to only support csv.
A couple of questions:

Can I use /tmp? How can I make sure it's deleted after I'm done? Even if some error occurs. Is there some kind of with statement across the pipeline?
How can I spew parameters to the next processor (i.e. filenames in a zip)? Should I use yield or modify datapackage?
Could find a link to excel processor. Is there a list of all processors available somewhere?

Downloader should support Excel files as well - see here for example: https://github.com/openspending/os-data-importers/blob/master/america/uruguay/fiscal.source-spec.yaml
The way to do it is to create a separate 'resource' in the datapackage for each of these files.
I need to add proper documentation for 'standard library' processors.


JSDoc comments preview ignores line breaks

atom-ternjs successfully finds the jsdoc comments for the below function, but the presentation of those comments as a single line of text impairs readability.

This is related to autocomplete-plus.
At the current state, only strings and no HTML is allowed or possible for documentation.
Maybe use this issue for further discussion: #62

Updating the issue,
autocomplete-plus now allows markdown in description, descriptionHTML property has been finally deprecated in favor of descriptionMarkdown for security reasons.
Not very sure how to approach this issue, using this new feature by merely
replacing <br> by 2 spaces could change other things not desired by the user, but I like the idea. 😋


Fix compile of stdsimd on powerpc with no flags

We're running into issues updating with rust-lang/rust#52535, so we need to get
this working without RUSTFLAGS enabling the altivec feature

cc @lu-zero

Fine for me
On Fri, Jul 20, 2018, 12:53 Alex Crichton<EMAIL_ADDRESS>wrote:

cc @lu-zero https://github.com/lu-zero
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang-nursery/stdsimd/pull/531#issuecomment-406660607,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOlpIRe1a_RWuba2WFtxFzIjEL-fv8Fks5uIgrvgaJpZM4VYbCr
.


ppwater: Watch 4th.co.in

ppwater requests the watch of the watch_keyword 4th\.co\.in. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

4th\.co\.in has been seen in 5 true positives, 0 false positives, and 0 NAAs.

Approved by rene in Charcoal HQ


TEST-256 Update README.md

Atomist closed this PR because it no longer contains any valid changes.

Atomist closed this PR because it no longer contains any valid changes.

Atomist closed this PR because it no longer contains any valid changes.

Atomist closed this PR because it no longer contains any valid changes.


Runners more resilient to docker login failure

Login to docker registry is now done in PreExec and in case it
fails, it also fails the whole service (leading to subsequent
service restart).
Also added set -eux -o pipefail to be better protected against
any silent failures.

Sure - no problem for me. I just do it by default on such scipts to know what's going on when there are problems, but no strong feelings about it.


[python] fix complaint raises by ruff check with xxx_pb2_grpc.py that generated by grpc_tools.

Closes #37455

Can be labelled as release notes: no


setup-rust-toolchain always uses toolchain file from repo root

(From #14.)
In avr-hal, there is a rust-toolchain.toml at the root of the repository which is used for building most things.  However, one component (ravedude) is built with a different toolchain which is specified in a rust-toolchain.toml file in the relevant subdirectory.
setup-rust-toolchain always uses the toolchain from the root rust-toolchain.toml which means that ravedude is also built using that toolchain instead of the one specified in its own rust-toolchain.toml file.  Additionally, because a rust-toolchain.toml file always takes precedence over a toolchain specified in the CI job definition, there is no way to override the toolchain in the CI manifest.

Yes, this action only looks at the root rust-toolchain.toml, but besides a slight inefficiency, this should not matter when using it. cargo and rustc are rustup proxies. If they detect that there is a rust-toolchain.toml file and the toolchain is not installed, it gets installed when needed. As long as you execute cargo inside the ravedude directory, I think everything should work out.
However, in your CI you execute cargo from the repository root, so the root rust-toolchain.toml will take priority here.
https://github.com/Rahix/avr-hal/blob/3c02df9df80e7585765644a87076680a2d99b29a/.github/workflows/ci.yml#L112-L123
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Install Rust
        uses: actions-rust-lang/setup-rust-toolchain@v1
        with:
          toolchain: stable
      - name: Install libudev
        run: sudo apt-get update && sudo apt-get install -y libudev-dev
      - name: Check ravedude
        run: |
          cargo check --manifest-path ravedude/Cargo.toml

If you change the last line to  cd ravedude && cargo check the correct rust-toolchain.toml should be selected.

How would you suggest to improve this action? Add a directory component to this toolchain check and let it default to ./?
https://github.com/actions-rust-lang/setup-rust-toolchain/blob/f3c84ee10bf5a86e7a5d607d487bf17d57670965/action.yml#L112

Since this seems to be a usage problem and there is no comment on how to improve the current status, I will close the issue. You are welcome to provide additional information later.


Fix Condensed Rail Tooltip Issue Storybook

Fixes #199

Changes proposed in this Pull Request:

If condensed=true is the default, storybook no longer has issues with creating/destroying tooltips.

I'm doing a sanity check just to make sure that the original issue is contained only to storybook.  Storybook has had a similar issue in the past already.

I'm doing a sanity check just to make sure that the original issue is contained only to storybook. Storybook has had a similar issue in the past already.

No issues found 👍


Add baseline ratio calculation example

Hey.
Thank you for building this project.
I have used sassline before.
Right now i am trying to implement your tool in a real life project.
The font i want to use is called Lelo
I got the following information from the Typedesigner:
Ascender: 1032
Descender: -328
Caps height: 648
x height: 468
1000 Units pro EM
So if i want to do the math.
(UnitsPerEm − hhea.Ascender − hhea.Descender) / (2 × UnitsPerEm)
[1000 - 1032 - (-328)] / [2 x 1000]
[1000 - 1360] / [2 x 1000]
-360 / 2000
= -0.18
Using the measure tool  i get a value of 0.268
Maybe you can point me to a solution. Thank you!

Hi,
Thanks for the feedback!
The Ascender and Descender values need to come from the hhea (horizontal header) OpenType table. These usually differ from the values in the font summary – to my knowledge those come from the OS/2 table.
E.g. for Roboto Black the values are the following:

hhea.Ascender
Ascender
hhea.Descender
Descender

1900
1536
-500
-512

So the calculation is (with 2048 units/em):
(2048 - 1900 - (-500)) / (2 x 2048) = 0,158203125
I recommend you open the font file in a font editor (e.g. RoboFont) or just upload it to the opentype.js font inspector and check the hhea table (see attached screenshot). If you still get the same values – this is rare but possible – please use the value from the measure tool. In my tests manual measurement still provides accurate results for font sizes up to a few hundred pixels.
Hope this helps!

Hey! Thanks for the fast response.
I have checked with the opentype.js tool. Getting the same values as i put in my example calculation.
Is it possible to have a negative value as a result?
One other thing i realised is.
For the desktop [.otf] font the measure tool result is 0.268
If i use activate the [.ttf] webfont in my system i get a result of 0.148
So i don't know really what to use: 0.268 or 0.148 or -0.18

In this case you should use the value from the measure tool with the webfont (0.148) as this will be served to the users of your site.

Thanks. I will do that. Looks ok > With a grid height of 10px and your settings from https://github.com/jamonserrano/plumber-sass/blob/gh-pages/scss/docs/_typography.scss it works half way....
But not sure about about how to use it with my standard base-font-size of 1em. Have to make some more tests. Maybe it would be nice to have the possibility to not have the grid-height as the font-size on the  element. Maybe fractions like teehan+lax used to do it - see here
As well i have to see how to calculate for a modular scale and make it responsive in my environment using bourbon and bitters
Should i close the "issue" is there another way to talk about the project and related ideas (if you are interested in that)?

Yes, let's close this issue and start a new one for the other discussion.


Annotate choices for Choice as Collection

This PR changes type annotation for choices argument on Choice from typing.Sequence[str] to typing.Collection[str]. Additional tests using list, tuple and set were also added.

fixes #2525

Checklist:

[x] Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
[x] Add or update relevant docs, in the docs folder and in code.
[x] Add an entry in CHANGES.rst summarizing the change and linking to the issue.
[ ] Add .. versionchanged:: entries in any relevant code docs.
[x] Run pre-commit hooks and fix any issues.
[x] Run pytest and tox, no tests failed.

See discussion in linked issue.


Fix clippy lints

Replace std::*::EPSILON with *::EPSILON, etc.

Not exactly sure what to do about the remaining CI failures.

Thanks for your work and apologies for the long wait!
The argmin-math tests are broken due to #509, will have to fix that in another PR or I may just do it in this one.

Fixes #509

Codecov Report
Attention: Patch coverage is 99.40476% with 2 lines in your changes missing coverage. Please review.

Project coverage is 91.49%. Comparing base (a9e3eb7) to head (e031083).

Files with missing lines
Patch %
Lines

crates/spectator/src/connection.rs
0.00%
2 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #504      +/-   ##
==========================================
- Coverage   92.08%   91.49%   -0.60%
==========================================
  Files         178      178
  Lines       24455    23623     -832
==========================================
- Hits        22520    21613     -907
- Misses       1935     2010      +75

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


[HUDI-4296] fix the bug that TestHoodieSparkSqlWriter.testSchemaEvolutionForTableType is flaky

Tips

Thank you very much for contributing to Apache Hudi.
Please review https://hudi.apache.org/contribute/how-to-contribute before opening a pull request.

What is the purpose of the pull request
Fix TestHoodieSparkSqlWriter.testSchemaEvolutionForTableType failed random
the reason for it is that:
1）when we use glob path to read hudi table (like spark.read.format("hudi").load("/tmp/tableName///*")).   spark will infer parquet schema auto,
2）when evolution happen,  hoodie table may exist different schema parquet files,  spark choose a parquet file  randomly to infer schema
3）once spark choose a old parquet file，an old schema will be used which is wrong.
Therefore  we should specify the schema to the latest commit schema since the table schema evolution.
Verify this pull request
(Please pick either of the following options)
This pull request is a trivial rework / code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end.
Added HoodieClientWriteTest to verify the change.
Manually verified the change by running a job locally.

Committer checklist

[ ] Has a corresponding JIRA in PR title & commit

[ ] Commit message is descriptive of the change

[ ] CI is green

[ ] Necessary doc changes done or have another open PR

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

@nsivabalan  @xushiyan could you pls help me fix this bug thanks


refactor: Exception telemetry processor

Changes include:

Creating a base exception telemetry processor, that can be extended based on fhir exceptions, normalization, etc.
Removing EventHubConfigurationTelemetryProcessor as it wasn't really using the "HandleException" but only logging the associated exception error metric.

I also have some files to re-arrange, eg: moving the exceptions outside the telemetry folder since they aren't really telemetry exceptions, etc. but will do that in 2nd iteration so that the 1st iteration can show the actual diff in these files for review.


Incomplete Fix: The quantities in stock are not verified in case of payment with PayPal

Questions
Answers

Description?
As the remaining quantity in stock is not checked when paying with PayPal or other forms that require a gateway payment, it is possible to complete the order and pay for an out-of-stock product even if this is not permitted.

Type?
bug fix

BC breaks?
no

Deprecations?
no

Fixed ticket?
Fixes #325

How to test?
1 - Create a cart with an available item. 2 - Proceed to checkout until the payment selection. 3 - Before confirming the order, modify the product quantity in the admin, making it unavailable. 4 - Confirm the order with PayPal. 5 - The system should refresh the page and redirect to the cart.

This fix generates the following error: "Uncaught Error: Expected an order id to be passed", because the "createOrder" function must return an order ID. Currently, in case of an unavailable item, it does not return anything and simply refreshes the page.
Does anyone have a suggestion on how to handle this?

Thank you @Codencode  for your PR. We will read it and try to merge it ASAP.

Hi @clotairer,
my solution checks if the cart/product is actually available just before creating the order, and it does this in the createOrder function.
If the cart/item is not available, the order ID is obviously not returned, and this generates an error/exception that is handled by the onError function, where I refresh the page. This way, the system redirects to the cart, showing that the product is no longer available.
Perhaps it could be managed differently, but this is the solution I came up with.
Thanks.

Hi,
It looks like we already fix your issue here
https://github.com/202ecommerce/paypal/pull/350
Could you confirm to us your module is up to date ?

Hi, It looks like we already fix your issue here #350
Could you confirm to us your module is up to date ?

Yes, the module is updated to the latest version 6.4.2.
I think fix #350 solves a different case.
The problem I encountered occurs when you are on a product page or in the cart and in the meantime the product has become unavailable.
My change, before starting the order creation process on PayPal, performs the availability check and if unavailable blocks the order.


Clean up variables under a name prefix

Instead of requiring a user to enter all resource names, the module should append the details of each resource to a standard name prefix in line with other modules.
For example,
ip_configuration_name = var.ip_configuration_name == "" ? "${var.name_prefix}-ipconfig" : var.ip_configuration_name

This was already done, however, the readme was not updated. Changing to an issue to update the readme.


Table per hierarchy on User class causes application not to start

[x] Steps to reproduce provided
[x] Stacktrace provided
[x] Example that reproduces the problem uploaded to Github
[x] Full description of the issue provided (see below)

Steps to Reproduce

Create a grails app
Install spring security core plugin compile 'org.grails.plugins:spring-security-core:4.0.0'
Add "tablePerHierarchy false" to User class
Extend another class from User

Expected Behaviour
It should create a separate table for the extended class.
Actual Behaviour
Application doesn't start and throws:
Disconnected from the target VM, address: '<IP_ADDRESS>:39131', transport: 'socket' 2020-05-08 19:15:10.534 ERROR --- [  restartedMain] o.s.b.web.embedded.tomcat.TomcatStarter  : Error starting Tomcat context. Exception: org.springframework.beans.factory.BeanCreationException. Message: Error creating bean with name 'authenticationProcessingFilterDeregistrationBean': Cannot resolve reference to bean 'authenticationProcessingFilter' while setting bean property 'filter'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'authenticationProcessingFilter': Cannot resolve reference to bean 'authenticationManager' while setting bean property 'authenticationManager'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'authenticationManager': Cannot resolve reference to bean 'daoAuthenticationProvider' while setting constructor argument with key [0]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'daoAuthenticationProvider': Cannot resolve reference to bean 'userDetailsService' while setting bean property 'userDetailsService'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'userDetailsService': Unsatisfied dependency expressed through method 'setTargetDatastore' parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'hibernateDatastore': Bean instantiation via constructor failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.grails.orm.hibernate.HibernateDatastore]: Constructor threw exception; nested exception is java.lang.NullPointerException 2020-05-08 19:15:10.584 ERROR --- [  restartedMain] o.s.boot.SpringApplication               : Application run failed
Complete stacktrace
The problem occurs only when trying to extend from the User class, it works ok with any other class.
Environment Information

Operating System: Linux Manjaro
GORM Version: 7.0.4
Grails Version: 4.0.3
JDK Version: 1.8 openjdk

Example Application
Github repository with example that reproduces the issue:
https://github.com/richardvil/spring-security-core-user-hierarchy-error

Same error is happening on Grails 6.1, JDK 11.0.3, Gorm Version: 8.0.0, groovyVersion: 3.0.11


Switched from network to chain terminology

Pull Request Test Coverage Report for Build 18

23 of 25 (92.0%) changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.03%) to 96.063%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

index.js
15
17
88.24%

Totals

Change from base Build 16:
0.03%

Covered Lines:
80

Relevant Lines:
83

💛  - Coveralls


Smooth scroll from top to bottom direction

Great library.
I am using [compile 'com.github.barteksc:android-pdf-viewer:2.5.1'] library.
I have only single page pdf which can be scrolled.
When I scroll from bottom to top direction the page is scrolled smoothly.
How can I implement the same thing when I scroll from top to bottom direction.

Should scroll both ways......

Try version 2.6.0, it improves fling.

Thanks...
Its too good.


Added computation method of the inertia matrix of a kinematic chain.

@categoryik Please see rkChainInertiaMatrix() in src/rk_chain.c.
I merged computations of the inertia matrix and the bias force vector into one function since they are often required at the same time.
You can also find an example (benchmark test) code, which I made based on your calc_dynamics_eq_items.c. Check it out for your reference.
Please close this issue if you are convinced with the revisions.

Thank you for informing me.
I felt the name rkChainInertiaMatrix() may lead misunderstand for users, because this method name not seems to calculate bias forces. For alternative, how is rkChainInertiaMatrixAndBias()?
The term And may be not your favor.

Makes sense. What do you think about rkChainInertiaMatBiasVec() ?

@zhidao I agree with your opinion.

Done.


Fix: quick-comment-edit appears on every comment

Related issues
Closes #4712 if merged.
This is an up-to-date version of #4749.
What this PR does
Does not add the edit button on comments from other users if the current user is not allowed to edit them.
Test URLs
https://github.com/facebook/jest/issues/6316 (locked issue)
https://github.com/facebook/jest/issues/11791 (regular issue)

edit-comments-faster only appears if you've already left a comment

I think that should be fixed by '#settings-tab' right?

Only for the owner, but not for collaborators

Hei

`FreH2506


feature request: using image from /assets/ for featured image

This allows multiple posts to share a same featured image without duplicate URL of redundant copies.
Thank you.

Make sense when using images parameter on front matter.


Snapchat browser is not being detected

Hi,
I used your code to detect snapchat browser but it did not detect.
Useragent: Mozilla/5.0 (iPhone; CPU iPhone OS 15_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.2 Mobile/15E148 Snapchat/<IP_ADDRESS> (like Safari/86<IP_ADDRESS>.4, panda)

Hi,
Snapchat has been added (see new release).


No longer tries to send download compete message every time ripme sav…

…es a url to a text file
Category
This change is exactly one of the following (please change [ ] to [x]) to indicate which:

[x] a bug fix (Fix #795)

Description
Removed the code that was trying to push a message to a null observer
Testing
Required verification:

[ ] I've verified that there are no regressions in mvn test (there are no new failures or errors).
[ ] I've verified that this change works as intended.

[ ] Downloads all relevant content.
[ ] Downloads content from multiple pages (as necessary or appropriate).
[ ] Saves content at reasonable file names (e.g. page titles or content IDs) to help easily browse downloaded content.

[ ] I've verified that this change did not break existing functionality (especially in the Ripper I modified).

Optional but recommended:

[ ] I've added a unit test to cover my change.

Coverage decreased (-0.03%) to 38.314% when pulling fc52da3497afadb745250ba39a1b297dccbbef88 on cyian-1756:cli_crash_fix into df6897504e4f107480da9f9e41f7497bc38562c9 on RipMeApp:master.

The failed test has nothing to do with these changes


Implement a context-aware object variable

Have a special variable named ^ that will contain information about the last command executed that generated a object. This will make it super simple to create new objects that are relative to the last one.
There will be 2 of these special variables:

@^ will contain the last object's ending coordinate (useful when building a group from a series of connected lines)
&^ will contain the whole last object

I was unable to find a easy way to implement the @^ variable without refactoring the variable getting and setting code at the moment, so I'll leave this for the future maybe.


Plane() initializer sometimes ignores arguments

In cases where named and positional arguments are mixed, like this (and probably many others, but this is the real-world example I ran into):
Plane((0, 0, 0), x_dir=(1, 0, 0), z_dir=(0, 0, 1))

the first argument is ignored by __init__, as it expects either all positional or all named arguments. IMO b3d should either attempt to handle mixed arguments somehow (e.g. in this case inferring that it’s the origin), or at least raise an error when it ignores an argument, so that the user is aware of what’s happening. Something like:
if args and kwargs:
  raise ValueError("Plane() initializer expects either positional OR named arguments, not both")

I've lot track of the commit that fixed this but:
from build123d import *

p = Plane((1, 1, 1), x_dir=(1, 0, 0), z_dir=(0, 0, 1))
print(p)

Plane(o=(1.00, 1.00, 1.00), x=(1.00, 0.00, 0.00), z=(0.00, 0.00, 1.00))

shows that it's fixed now.


[WIP] Watch OS signals when providing --verbose flag

What type of PR is this?
/kind feature

What this PR does / why we need it:
When providing the --verbose flag to the auditor, all OS signals are logged when encountered. The two exceptions are SIGKILL and SIGSTOP as the os/signal package cannot catch these signals.
Capturing all OS signals may gain insight into how and why the auditor keeps restarting #353
Which issue(s) this PR fixes:
Part of #353
Special notes for your reviewer:
Does this PR introduce a user-facing change?
YES
When providing the auditor with the --verbose, debug messages will be logged like so:
DEBU Watching for OS Signals...                    file="signals/signals.go:50"
INFO Defaulting to port 8080                       file="audit/auditor.go:94"
INFO Listening on port 8080                        file="audit/auditor.go:97"
DEBU Encoutered signal: bus error                  file="signals/signals.go:52"
DEBU Encoutered signal: floating point exception   file="signals/signals.go:52"
DEBU Encoutered signal: urgent I/O condition       file="signals/signals.go:52"
DEBU Encoutered signal: signal 54                  file="signals/signals.go:52"
DEBU Encoutered signal: urgent I/O condition       file="signals/signals.go:52"
DEBU Encoutered signal: child exited               file="signals/signals.go:52"
DEBU Encoutered signal: trace/breakpoint trap      file="signals/signals.go:52"
DEBU Encoutered signal: window changed             file="signals/signals.go:52"
DEBU Encoutered signal: urgent I/O condition       file="signals/signals.go:52"
DEBU Encoutered signal: urgent I/O condition       file="signals/signals.go:52"

Observe all OS signals directed to the auditor when passing the --verbose flag.

cc: @listx @amwat @justaugustus @kubernetes-sigs/release-engineering

We have two options when observing OS signals.

Observe all signals
Pro: Capture all behavior directed to the auditor (hopefully determine why the auditor is restarting in cloud run)
Con: We must manually define which signals to terminate on. Otherwise, we ignore the signal.
Observe a few specific signals
Pro: Gain insight on the specific signals we care about (termination signals)
Con: We may miss out on signals that show underlying errors causing the auditor to fail.

Thanks!
/lgtm
/approve


fix(tdsuite): verbose tests raised an error

Closes #252.

coverage: 99.865%. remained the same
when pulling 25fd1ca997b0e58cd042346f654dd8983afbdf52 on fix-suite-test-v
into 6250333f07babbee89d1de8935d44c2f0a5dfbd0 on master.


String OR validation

Is it possible to validate a string field that should be either empty (len == 0) or of len == 2. I don't see how that could be done today. Or am I mistaken? Would you accept a PR for such a feature?

Hey! In this case, I'd normally recommend the StringValue WKT since you're really wanting to specify is that the field is optional, but otherwise must be 2 chars. If that's not an option, it might make sense to a do a len_in rule. Long term, we will likely be adding a basic predicate/expression syntax to describe these more complex rules.

Hey. Yes, of course. StringValue will work just fine in this case. Thanks for the suggestion.


feat: continental university added

Institution/School Name
Universidad Continental
Instiution/School Website
https://ucontinental.edu.pe/

@philipto ok, thanks for the information


Add sp_cert_multi to facilitate SP cert/key rotation

Fixes https://github.com/SAML-Toolkits/ruby-saml/issues/560
This PR introduces sp_cert_multi parameter which is analogous to idp_cert_multi. It allows developers to have fine-grained control over SP certs and private keys, including:

Allow SP to have separate SP signing and encryption keys (required by some governmental regulations.)
Allow SP to rotate SP private keys, not just certificates (for example, if key becomes compromised.)
Allow SP to have more than two concurrent pairs of SP certs/keys in rotation at once.

The changes are summarized as follows:

Add SamlSettings sp_cert_multi parameter. It has the following shape:
sp_cert_multi = {
  signing: [
    { certificate: cert1, private_key: private_key1 },
    { certificate: cert2, private_key: private_key2 }
  ],
  encryption: [
    { certificate: cert1, private_key: private_key1 },
    { certificate: cert3, private_key: private_key3 }
  ],
}

(Note: You can use same certs for signing/encryption, and same PK everywhere. It's completely backward compatible with current functionality.)

sp_cert_multi is mutually exclusive with the following: certificate, certificate_new, private_key.

If security[:check_sp_cert_expiry] is true, Ruby Saml automatically uses the first non-expired certificate in sp_cert_multi[:signing] for signing, and only uses private keys associated with non-expired certs in sp_cert_multi[:encryption] for decryption. This is evaluated in realtime, so as soon as your old cert expires your app automatically starts signing with the new one.

The validation error :check_sp_cert_expiration is now raised only if ALL SP certs are expired. This is a slight behavior change;

Previously if Settings.certificate was expired but Settings.certificate_new was not, an error would be raised.
In this PR this case does not raise an error and starts automatically using certificate_new for signing. (This case was not previously in the tests, but I've now added a test for it with the new logic.)

:check_sp_cert_expiration now also validates the certificate not_before condition; previously it was only validating not_after.

I did not add it in this PR, but we should also do the same thing for IdP certs--see here: https://github.com/SAML-Toolkits/ruby-saml/issues/674)

If :check_sp_cert_expiration is true, we now no longer include expired certs in the generated SP metadata. This is a good practice because having expired certs may cause the IdP system to throw an error, depending on how strictly it does its validation.

Point of discussion: It's debatable if we want to include "not_before" certs here (i.e. not yet ready to use, but ok for IdP to pre-cache and use when ready.) For simplicity's sake I've excluded them, especially because "not_before" is relatively rare in the wild.

Refactor so that internal references to get_sp_cert, get_sp_private_key, etc. now point to the new structure of multiple certs.

When performing decryption, we now try all private keys under sp_cert_multi[:encryption] (this is analogous to how we try all IDP certs in idp_cert_multi[:signing] when verifiying the IDP signature.)

Extract out OneLogin::RubySaml::Utils.build_cert_object and build_private_key_object.

Deprecate the certificate_new parameter since sp_cert_multi fulfills the same role better. It still works but it is removed from the docs.

When there are multiple SP certs, the ordering of SP KeyDescriptor node in the SP metadata XML will now be all signing keys first, and then all encryption keys. (Previously it would be signing, encryption, signing, encryption.) This does not affect XML integrity in any way.

This PR contains unit tests and integration tests for all major SP signing flows (both Redirect and POST). Decryption is covered as well.

@pitbulk this is ready for final review. Let me know what I can do to help get this merged.

FYI I am using this in production now without issues.

@pitbulk what do you think?

I will be adding this on next ruby-saml release. Hopefully soon.

@pitbulk any update? I've been using this in prod for 6 different SAML integrations, with IdPs on Azure AD, PingFederate, etc. I think it's safe to merge.

Sorry for the delay on merging it, I will be more active now with ruby-saml

Excellent news, thank you!


Run tests on all supported k8s versions

Since we support 3 versions of Kubernetes, we should also test all of them.
For example, if by accident we introduce a dependency on an API version that isn't supported in previous versions of Kubernetes than the latest one, we won't catch it with our current test suite (which only runs latest).

How about we also start running test on semaphore CI, so we could have 3 CI hooked to the operator repo, so each CI would test one k8s version? :)

I think this is blocked by our move to running tests on CircleCI.
Once that's done for the current k8s version, we can use workflows to spawn builds on multiple clusters.

Fixed in #304


Meteor Accounts Emails

Is it possible to use this package to override/customize the Meteor accounts emails sent by sendResetPasswordEmail, sendEnrollmentEmail, and sendVerificationEmail?
thanks!

Hi @joshperrin. Yep, it's possible with the Mailer.render function: http://lookback.github.io/meteor-emails/docs/mailer.html#section-12. You'll get back a plain string with which you can attach to the Accounts props. Not sure if they accept HTML though, but I think so.

Hey @johanbrook thanks for your response. Works great! Is there a way to render the plain text version?

The render function only returns HTML for now. You can use an external npm module to convert HTML to plain text. But we should probably return an object from render with both plain text and HTML in the future..


Different account ids on the same account

transfer clayoptest1 clayoptest23 20000 CORE "" true
3421351ms th_a       wallet.cpp:529                get_account          ] my account id 1.2.
91535 different from blockchain id 1.2.91533

get_account clayoptest23
327991ms th_a       wallet.cpp:529                get_account          ] my account id 1.2.91535 different from blockchain id 1.2.91533
{
"id": "1.2.91535",
"membership_expiration_date": "1970-01-01T00:00:00",
"registrar": "1.2.17269",
"referrer": "1.2.17269",
"lifetime_referrer": "1.2.17269",

I suspect cli_wallet account caching behavior, I'm thinking maybe the registration initially reported to the cli_wallet happened on a different fork (so the account had a different ID).  And the cli_wallet has no way to update the ID of an account, it just assumes the ID will always be correct and immutable -- but this isn't true in the presence of forks.

The CLI wallet needs to be updated to be more reliable with respect to caching.

This issue was moved to bitshares/bitshares-core#98


XMLHttpRequest Does not support Request methods with empty body on Android 5,6

The "http verbs" - POST, PUT, DELETE are replaced with GET in XMLHttpRequest when there is no content in the body.
This is a critical issue as it breaks the functionality of some javascript SDKs and libraries.
It's also very confusing because a DELETE request will send a GET which returns status 200 in a decent REST api.
var page = new tabris.Page({
  title: "XMLHttpRequest Android Bug",
  topLevel: true
});

new tabris.Button({
  layoutData: {left: 10, top: 10},
  text: "Send an XMLHttpRequest with a verb "
}).on("select", function() {
  var xhr = new tabris.XMLHttpRequest();
  xhr.onreadystatechange = function() {
    if (xhr.readyState === xhr.DONE) {
      console.log("DONE");
    }
  };
  // Whatever Request Method you choose - GET, POST, PUT, DELETE,
  // on Android (5,6) it will always send a GET request.
  xhr.open("GET", "https://YOUR_TUNNEL.ngrok.io");
  xhr.send();
}).appendTo(page);

page.open();

Fixed on the android side.


do not fail if response is not json (e.g. xml)

This PR fixes a bug where non-JSON (e.g. XML) responses will cause failure.
Sister function _request_with_access_token has no such bug.
I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.

Applicable tests pass.
Thanks a lot @mkevac. Aiming to release a new version with this soon.


シーケンス図のウィンドウの枠と目的の枠の区別がつきづらいので色を変えたほうがいい

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

修正済みのためクローズ


test failed

I have configured the symsan environment in two virtual machines. When I conducted the final test, all test cases in one of the virtual machines failed, while only three of them passed in the other. I don't know if this is a normal phenomenon.

If this is abnormal, where should I check?

I've configured the environment of SYMSAN similarly to your Figure 1. While I managed to pass 3 test cases, and failures in 21. I think this is not right, perhaps some configuration are not set properly. Have you been able to find a solution for this issue?
@lz1159435992 @chenju2k6 @ChengyuSong

I can reproduce the issue. Looks all cpp tests pass but all c test failed. Let me figure out why.

Looks like compiling C programs needs libunwind library. I just submitted a PR #23  which installs libunwind-dev in the docker containers.
If you test with docker, you should be able to see 25 out 26 tests pass.  See my results as below:
-- Testing: 26 tests, 26 workers --
FAIL: SymSan :: bitflip/bitflip.c (1 of 26)
PASS: SymSan :: unaligned_load.c (2 of 26)
PASS: SymSan :: shift_and.c (3 of 26)
PASS: SymSan :: sign.c (4 of 26)
PASS: SymSan :: cf1.c (5 of 26)
PASS: SymSan :: call_fn2.c (6 of 26)
PASS: SymSan :: call_fn3.c (7 of 26)
PASS: SymSan :: memcmp.c (8 of 26)
PASS: SymSan :: pointer.c (9 of 26)
PASS: SymSan :: bitflip.c (10 of 26)
PASS: SymSan :: strcmp2.c (11 of 26)
PASS: SymSan :: if_eq.c (12 of 26)
PASS: SymSan :: partial_concrete.c (13 of 26)
PASS: SymSan :: infer_type.c (14 of 26)
PASS: SymSan :: mini.c (15 of 26)
PASS: SymSan :: call_fn.c (16 of 26)
PASS: SymSan :: gep.c (17 of 26)
PASS: SymSan :: strcmp.c (18 of 26)
PASS: SymSan :: switch.c (19 of 26)
PASS: SymSan :: bool.c (20 of 26)
PASS: SymSan :: mini2.c (21 of 26)
PASS: SymSan :: context.c (22 of 26)
PASS: SymSan :: aggregate.c (23 of 26)
PASS: SymSan :: cpp_string.cpp (24 of 26)
PASS: SymSan :: cpp_map.cpp (25 of 26)
PASS: SymSan :: cpp_fstream.cpp (26 of 26)
********************
Failed Tests (1):
  SymSan :: bitflip/bitflip.c

Testing Time: 1.63s
  Passed: 25
  Failed:  1

If you are testing on Ubuntu, you can probably fix the issue by
apt install libunwind-dev
I will check why bitflip fails the test.

After installinglibunwind-dev, all 24 test cases in one of the virtual machines passed, while all of them still failed in the other virtual machine. It seems that there might be some issues with my compilation configuration.

you can check the failure details by using lit -v

Reproduce the same issue on ubuntu 20.04.
lit tests -v reports it cannot find libunwind.so.1.
Run the following commands:
ls /usr/lib/x86_64-linux-gnu/libunwind.*

From the output, /usr/lib/x86_64-linux-gnu/libunwind.so  /usr/lib/x86_64-linux-gnu/libunwind.so.8 presents but no /usr/lib/x86_64-linux-gnu/libunwind.so.1
Workaround:
cd /usr/lib/x86_64-linux-gnu/
ln -s libunwind.so.8 libunwind.so.1

This will create a symbol link for libunwind.so.1 point to libunwind.so.8 which will solve the issue.


Add support for Google Cloud Storage

Closes #23

The pipeline fails with the following exception:
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':sonarqube'.
> Not authorized. Please check the property sonar.login or SONAR_TOKEN env variable

The pipeline fails with the following exception:
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':sonarqube'.
> Not authorized. Please check the property sonar.login or SONAR_TOKEN env variable

This happens on all external builds. It is a security feature of Azure. We probably should disable this step on external builds


AVRO-4040: [java] @AvroInternal annotation for getSchema() and getSpecificData() methods

What is the purpose of the change
This pull request introduces @AvroInternal annotation interface that serves only to identify the semantics of being something internal/avro specific.
Thanks to this indicator annotation, class processors can ignore those avro-specific fields not coming from user defined schema.
Fixes https://issues.apache.org/jira/browse/AVRO-4040
Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Documentation
I think we could mention this interface in some docs.

I've fixed spotless error, so build should pass now ;)

https://github.com/bgalek/avro/actions/runs/10610238789/job/29407344572 it passed on my org ;)

Any chances for merge? :)

@opwvhk hi, do we have any ETA for this PR?

@opwvhk any updates?

@opwvhk 👋 ?

anyone? :)

sure thing, I'll add those tests - will you help me with merging this afterwards? :)

will you help me with merging this afterwards?

I am trying to not step on my Java mates' toes but I think I could help you here ! ;-)

@martin-g I've gone through the repo test suites, and it seems that relevant tests that I've updated are already covering my case since they compare an avro-generated Java class with its java-compiled counterpart.
If there is a testuite that I could extend - I would need some directions. Can avro team help me ship this feature in 2024? :)

Which test(s) cover the Enum and Fixed cases ?

AFAIK lang/java/avro/src/test/java/org/apache/avro/TypeEnum.java is beeing compared with class generated from avro schema

maybe you could point me to an example test that I missed that I could extend/blueprint?

I don't use Java (in general) for several years now ...
I really have no idea how those classes are being used/tested. And I don't have the time to investigate ...
I just wanted to see a new test that introduces some record, enum and fixed schemas, generates .java classes for them and then uses reflection to verify the existence of the new annotation.
I'm afraid you will have to wait someone from the Java team to take a look.

@martin-g I get it; thank you for your dedication to help!
Is there an user that I should mention/ping about this PR? :)

Is there an user that I should mention/ping about this PR? :)

Everyone from the team is already notified, so there is no need of personal pings.
I cannot say why there is no reaction. Maybe lack of time, maybe something else ...

@martin-g I get it, but even "we won't make it this year" answer is better than no answer ;)
I also did not find any clean workaround for my problem (only "semi-bad" ones like harcoding avro field/method names in springdoc...)

please, can anyone check this small pr?

is there anyone?


UI does not show all running workflows (it used to do so) / UI and argo list differ (missing running workflows)

Pre-requisites

[X] I have double-checked my configuration
[X] I can confirm the issues exists when I tested with :latest
[ ] I'd like to contribute the fix myself (see contributing guide)

What happened/what you expected to happen?
When I am submitting a workflow in the UI it is shown in the list of running workflows. When refreshing this page all workflows should be listed.
We just upgraded to argo 3.4.0 and not all running workflows are shown in the UI. When you wait long enough eventually workflows pop up. In our day to day work we noticed that workflows seem to be added to the UI once a transition happens, i.e. when a new step is entered in the workflow.
In short: The output of argo list and the workflows shown in the UI are not the same. Some running flows are missing. They are being added once they transition from one node to another while the UI is shown.
Version
3.4.0
Paste a small workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: zargo-debug-child
  namespace: argo
spec:
  entrypoint: main
  templates:
    - name: main
      steps:
        - - name: node1
            template: work
        - - name: node2
            template: work
    - name: work
      script:
        image: bash:5.2.0-alpine3.15
        command:
          - bash
        source: |
          echo "Doing some work for 60 seconds"
          sleep 60

Logs from the workflow controller
time="2022-09-27T15:57:49.577Z" level=info msg="Processing workflow" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:57:49.591Z" level=info msg="Updated phase  -> Running" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:57:49.593Z" level=info msg="Steps node zargo-debug-child-vcmgq initialized Running" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:57:49.593Z" level=info msg="StepGroup node zargo-debug-child-vcmgq-3865638504 initialized Running" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:57:49.593Z" level=info msg="Pod node zargo-debug-child-vcmgq-3922648685 initialized Pending" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:57:49.628Z" level=info msg="Created pod: zargo-debug-child-vcmgq[0].node1 (zargo-debug-child-vcmgq-work-3922648685)" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:57:49.628Z" level=info msg="Workflow step group node zargo-debug-child-vcmgq-3865638504 not yet completed" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:57:49.628Z" level=info msg="TaskSet Reconciliation" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:57:49.628Z" level=info msg=reconcileAgentPod namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:57:49.639Z" level=info msg="Workflow update successful" namespace=argo phase=Running resourceVersion=10435392 workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:57:59.629Z" level=info msg="Processing workflow" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:57:59.629Z" level=info msg="Task-result reconciliation" namespace=argo numObjs=0 workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:57:59.629Z" level=info msg="node changed" namespace=argo new.message= new.phase=Running new.progress=0/1 nodeID=zargo-debug-child-vcmgq-3922648685 old.message= old.phase=Pending old.progress=0/1 workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:57:59.629Z" level=info msg="Workflow step group node zargo-debug-child-vcmgq-3865638504 not yet completed" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:57:59.629Z" level=info msg="TaskSet Reconciliation" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:57:59.629Z" level=info msg=reconcileAgentPod namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:57:59.726Z" level=info msg="Workflow update successful" namespace=argo phase=Running resourceVersion=10435445 workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:01.782Z" level=info msg="Processing workflow" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:01.782Z" level=info msg="Task-result reconciliation" namespace=argo numObjs=0 workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:01.782Z" level=warning msg="workflow uses legacy/insecure pod patch, see https://argoproj.github.io/argo-workflows/workflow-rbac/" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:01.782Z" level=info msg="node changed" namespace=argo new.message= new.phase=Succeeded new.progress=0/1 nodeID=zargo-debug-child-vcmgq-3922648685 old.message= old.phase=Running old.progress=0/1 workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:01.782Z" level=info msg="Step group node zargo-debug-child-vcmgq-3865638504 successful" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:01.782Z" level=info msg="node zargo-debug-child-vcmgq-3865638504 phase Running -> Succeeded" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:01.782Z" level=info msg="node zargo-debug-child-vcmgq-3865638504 finished: 2022-09-27 15:59:01.78294768 +0000 UTC" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:01.787Z" level=info msg="StepGroup node zargo-debug-child-vcmgq-2858834269 initialized Running" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:01.787Z" level=info msg="SG Outbound nodes of zargo-debug-child-vcmgq-3922648685 are [zargo-debug-child-vcmgq-3922648685]" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:01.788Z" level=info msg="Pod node zargo-debug-child-vcmgq-3116902745 initialized Pending" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:01.818Z" level=info msg="Created pod: zargo-debug-child-vcmgq[1].node2 (zargo-debug-child-vcmgq-work-3116902745)" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:01.818Z" level=info msg="Workflow step group node zargo-debug-child-vcmgq-2858834269 not yet completed" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:01.818Z" level=info msg="TaskSet Reconciliation" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:01.818Z" level=info msg=reconcileAgentPod namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:01.828Z" level=info msg="Workflow update successful" namespace=argo phase=Running resourceVersion=10435675 workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:01.834Z" level=info msg="cleaning up pod" action=labelPodCompleted key=argo/zargo-debug-child-vcmgq-work-3922648685/labelPodCompleted
time="2022-09-27T15:59:11.820Z" level=info msg="Processing workflow" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:11.820Z" level=info msg="Task-result reconciliation" namespace=argo numObjs=0 workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:11.820Z" level=info msg="node changed" namespace=argo new.message= new.phase=Running new.progress=0/1 nodeID=zargo-debug-child-vcmgq-3116902745 old.message= old.phase=Pending old.progress=0/1 workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:11.820Z" level=info msg="SG Outbound nodes of zargo-debug-child-vcmgq-3922648685 are [zargo-debug-child-vcmgq-3922648685]" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:11.821Z" level=info msg="Workflow step group node zargo-debug-child-vcmgq-2858834269 not yet completed" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:11.821Z" level=info msg="TaskSet Reconciliation" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:11.821Z" level=info msg=reconcileAgentPod namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T15:59:11.834Z" level=info msg="Workflow update successful" namespace=argo phase=Running resourceVersion=10435730 workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.417Z" level=info msg="Processing workflow" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.417Z" level=info msg="Task-result reconciliation" namespace=argo numObjs=0 workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.417Z" level=warning msg="workflow uses legacy/insecure pod patch, see https://argoproj.github.io/argo-workflows/workflow-rbac/" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.417Z" level=info msg="node changed" namespace=argo new.message= new.phase=Succeeded new.progress=0/1 nodeID=zargo-debug-child-vcmgq-3116902745 old.message= old.phase=Running old.progress=0/1 workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.417Z" level=info msg="SG Outbound nodes of zargo-debug-child-vcmgq-3922648685 are [zargo-debug-child-vcmgq-3922648685]" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.417Z" level=info msg="Step group node zargo-debug-child-vcmgq-2858834269 successful" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.417Z" level=info msg="node zargo-debug-child-vcmgq-2858834269 phase Running -> Succeeded" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.417Z" level=info msg="node zargo-debug-child-vcmgq-2858834269 finished: 2022-09-27 16:00:13.417764045 +0000 UTC" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.417Z" level=info msg="Outbound nodes of zargo-debug-child-vcmgq-3116902745 is [zargo-debug-child-vcmgq-3116902745]" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.417Z" level=info msg="Outbound nodes of zargo-debug-child-vcmgq is [zargo-debug-child-vcmgq-3116902745]" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.417Z" level=info msg="node zargo-debug-child-vcmgq phase Running -> Succeeded" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.417Z" level=info msg="node zargo-debug-child-vcmgq finished: 2022-09-27 16:00:13.41780197 +0000 UTC" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.417Z" level=info msg="Checking daemoned children of zargo-debug-child-vcmgq" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.417Z" level=info msg="TaskSet Reconciliation" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.417Z" level=info msg=reconcileAgentPod namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.417Z" level=info msg="Running OnExit handler: b72ca92baf93-exit-handler" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.419Z" level=info msg="Steps node zargo-debug-child-vcmgq-4002967377 initialized Running" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.419Z" level=info msg="StepGroup node zargo-debug-child-vcmgq-3620866933 initialized Running" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.419Z" level=info msg="Pod node zargo-debug-child-vcmgq-1020052388 initialized Pending" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.438Z" level=info msg="Created pod: zargo-debug-child-vcmgq.onExit[0].success (zargo-debug-child-vcmgq-b72ca92baf93-send-slack-1020052388)" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.438Z" level=info msg="Skipping zargo-debug-child-vcmgq.onExit[0].failure: when 'Succeeded != Succeeded' evaluated false" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.438Z" level=info msg="Skipped node zargo-debug-child-vcmgq-1275290133 initialized Skipped (message: when 'Succeeded != Succeeded' evaluated false)" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.438Z" level=info msg="Workflow step group node zargo-debug-child-vcmgq-3620866933 not yet completed" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.448Z" level=info msg="Workflow update successful" namespace=argo phase=Running resourceVersion=10436003 workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:13.455Z" level=info msg="cleaning up pod" action=labelPodCompleted key=argo/zargo-debug-child-vcmgq-work-3116902745/labelPodCompleted
time="2022-09-27T16:00:23.440Z" level=info msg="Processing workflow" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.440Z" level=info msg="Task-result reconciliation" namespace=argo numObjs=0 workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.440Z" level=warning msg="workflow uses legacy/insecure pod patch, see https://argoproj.github.io/argo-workflows/workflow-rbac/" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.440Z" level=info msg="node changed" namespace=argo new.message= new.phase=Succeeded new.progress=0/1 nodeID=zargo-debug-child-vcmgq-1020052388 old.message= old.phase=Pending old.progress=0/1 workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.441Z" level=info msg="TaskSet Reconciliation" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.441Z" level=info msg=reconcileAgentPod namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.441Z" level=info msg="Running OnExit handler: b72ca92baf93-exit-handler" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.441Z" level=info msg="Step group node zargo-debug-child-vcmgq-3620866933 successful" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.441Z" level=info msg="node zargo-debug-child-vcmgq-3620866933 phase Running -> Succeeded" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.441Z" level=info msg="node zargo-debug-child-vcmgq-3620866933 finished: 2022-09-27 16:00:23.441636451 +0000 UTC" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.441Z" level=info msg="Outbound nodes of zargo-debug-child-vcmgq-1020052388 is [zargo-debug-child-vcmgq-1020052388]" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.441Z" level=info msg="Outbound nodes of zargo-debug-child-vcmgq-1275290133 is [zargo-debug-child-vcmgq-1275290133]" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.441Z" level=info msg="Outbound nodes of zargo-debug-child-vcmgq-4002967377 is [zargo-debug-child-vcmgq-1020052388 zargo-debug-child-vcmgq-1275290133]" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.441Z" level=info msg="node zargo-debug-child-vcmgq-4002967377 phase Running -> Succeeded" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.441Z" level=info msg="node zargo-debug-child-vcmgq-4002967377 finished: 2022-09-27 16:00:23.44170012 +0000 UTC" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.441Z" level=info msg="Checking daemoned children of zargo-debug-child-vcmgq-4002967377" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.441Z" level=info msg="Updated phase Running -> Succeeded" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.441Z" level=info msg="Marking workflow completed" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.441Z" level=info msg="Marking workflow as pending archiving" namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.441Z" level=info msg="Checking daemoned children of " namespace=argo workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.447Z" level=info msg="cleaning up pod" action=deletePod key=argo/zargo-debug-child-vcmgq-1340600742-agent/deletePod
time="2022-09-27T16:00:23.462Z" level=info msg="Workflow update successful" namespace=argo phase=Succeeded resourceVersion=10436076 workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.646Z" level=info msg="archiving workflow" namespace=argo uid=cdd6c373-96d9-4c98-b894-3ef1f02b18a2 workflow=zargo-debug-child-vcmgq
time="2022-09-27T16:00:23.650Z" level=info msg="cleaning up pod" action=labelPodCompleted key=argo/zargo-debug-child-vcmgq-b72ca92baf93-send-slack-1020052388/labelPodCompleted
time="2022-09-27T16:00:23.669Z" level=info msg="Queueing Succeeded workflow argo/zargo-debug-child-vcmgq for delete in 18h0m0s due to TTL"

Logs from in your workflow's wait container
time="2022-09-27T15:58:52.538Z" level=info msg="Creating minio client using static credentials" endpoint=s3.amazonaws.com
time="2022-09-27T15:58:52.544Z" level=info msg="Saving file to s3" bucket=incrmntal-argo-artifactory endpoint=s3.amazonaws.com key=incrmntal-prod-two/argo/zargo-debug-child-vcmgq/2022-09-27-zargo-debug-child-vcmgq-work-3922648685/main.log path=/tmp/argo/outputs/logs/main.log
time="2022-09-27T15:58:52.587Z" level=info msg="Save artifact" artifactName=main-logs duration=49.392744ms error="<nil>" key=incrmntal-prod-two/argo/zargo-debug-child-vcmgq/2022-09-27-zargo-debug-child-vcmgq-work-3922648685/main.log
time="2022-09-27T15:58:52.587Z" level=info msg="not deleting local artifact" localArtPath=/tmp/argo/outputs/logs/main.log
time="2022-09-27T15:58:52.587Z" level=info msg="Successfully saved file: /tmp/argo/outputs/logs/main.log"
time="2022-09-27T15:58:52.599Z" level=info msg="Create workflowtaskresults 403"
time="2022-09-27T15:58:52.599Z" level=warning msg="failed to patch task set, falling back to legacy/insecure pod patch, see https://argoproj.github.io/argo-workflows/workflow-rbac/" error="workflowtaskresults.argoproj.io is forbidden: User \"system:serviceaccount:argo:argo\" cannot create resource \"workflowtaskresults\" in API group \"argoproj.io\" in the namespace \"argo\""
time="2022-09-27T15:58:52.618Z" level=info msg="Patch pods 200"
time="2022-09-27T15:58:52.621Z" level=info msg="Deadline monitor stopped"
time="2022-09-27T15:58:52.621Z" level=info msg="Alloc=7002 TotalAlloc=16520 Sys=24018 NumGC=5 Goroutines=9"

@terrytangyuan Are you saying this is the cause for the regression I am seeing?
The workflows do show up when a transition occurs. Also completed workflows are shown correctly. Just running ones are not.
Also I installed argo from the install.yaml as per the release, so the roles and cluster roles are the vanilla roles from v3.4.0 – this should surely not miss any permissions?

time="2022-09-27T16:00:23.646Z" level=info msg="archiving workflow" namespace=argo uid=cdd6c373-96d9-4c98-b894-3ef1f02b18a2 workflow=zargo-debug-child-vcmgq

This indicates that you are archiving the workflows. Could you check if they are in your list of archived workflows?

First things first. So I did patch the respective role with the missing permissions. I changed the argo-cluster-role as per the vanilla install yaml at https://github.com/argoproj/argo-workflows/releases/download/v3.4.0/install.yaml from
- apiGroups:
  - argoproj.io
  resources:
  - workflowtaskresults
  verbs:
  - list
  - watch
  - deletecollection

to
- apiGroups:
  - argoproj.io
  resources:
  - workflowtaskresults
  verbs:
  - list
  - watch
  - deletecollection
  - create
  - patch

The warnings are now gone. Here is the complete logs from a rerun. However the problem that I am describing exists in the same way.
Wait Container logs:
time="2022-09-27T16:50:02.568Z" level=info msg="Starting Workflow Executor" version=v3.4.0
time="2022-09-27T16:50:02.570Z" level=info msg="Using executor retry strategy" Duration=1s Factor=1.6 Jitter=0.5 Steps=5
time="2022-09-27T16:50:02.570Z" level=info msg="Executor initialized" deadline="0001-01-01 00:00:00 +0000 UTC" includeScriptOutput=false namespace=argo podName=zargo-debug-child-qnxdn-work-1688663510 template="{\"name\":\"work\",\"inputs\":{},\"outputs\":{},\"metadata\":{\"annotations\":{\"cluster-autoscaler.kubernetes.io/safe-to-evict\":\"false\"}},\"script\":{\"name\":\"\",\"image\":\"bash:5.2.0-alpine3.15\",\"command\":[\"bash\"],\"resources\":{},\"source\":\"echo \\\"Doing some work for 60 seconds\\\"\\nsleep 60\\n\"},\"archiveLocation\":{\"archiveLogs\":true,\"s3\":{\"endpoint\":\"s3.amazonaws.com\",\"bucket\":\"incrmntal-argo-artifactory\",\"region\":\"us-east-1\",\"insecure\":false,\"accessKeySecret\":{\"name\":\"argo-s3-config\",\"key\":\"accessKey\"},\"secretKeySecret\":{\"name\":\"argo-s3-config\",\"key\":\"secretKey\"},\"encryptionOptions\":{},\"key\":\"incrmntal-prod-two/argo/zargo-debug-child-qnxdn/2022-09-27-zargo-debug-child-qnxdn-work-1688663510\"}},\"serviceAccountName\":\"argo\"}" version="&Version{Version:v3.4.0,BuildDate:2022-09-19T03:47:58Z,GitCommit:047952afd539d06cae2fd6ba0b608b19c1194bba,GitTag:v3.4.0,GitTreeState:clean,GoVersion:go1.18.6,Compiler:gc,Platform:linux/amd64,}"
time="2022-09-27T16:50:02.570Z" level=info msg="Starting deadline monitor"
time="2022-09-27T16:51:03.582Z" level=info msg="Main container completed" error="<nil>"
time="2022-09-27T16:51:03.582Z" level=info msg="No Script output reference in workflow. Capturing script output ignored"
time="2022-09-27T16:51:03.582Z" level=info msg="No output parameters"
time="2022-09-27T16:51:03.582Z" level=info msg="No output artifacts"
time="2022-09-27T16:51:03.582Z" level=info msg="S3 Save path: /tmp/argo/outputs/logs/main.log, key: incrmntal-prod-two/argo/zargo-debug-child-qnxdn/2022-09-27-zargo-debug-child-qnxdn-work-1688663510/main.log"
time="2022-09-27T16:51:03.582Z" level=info msg="Creating minio client using static credentials" endpoint=s3.amazonaws.com
time="2022-09-27T16:51:03.590Z" level=info msg="Saving file to s3" bucket=incrmntal-argo-artifactory endpoint=s3.amazonaws.com key=incrmntal-prod-two/argo/zargo-debug-child-qnxdn/2022-09-27-zargo-debug-child-qnxdn-work-1688663510/main.log path=/tmp/argo/outputs/logs/main.log
time="2022-09-27T16:51:03.637Z" level=info msg="Save artifact" artifactName=main-logs duration=54.307792ms error="<nil>" key=incrmntal-prod-two/argo/zargo-debug-child-qnxdn/2022-09-27-zargo-debug-child-qnxdn-work-1688663510/main.log
time="2022-09-27T16:51:03.637Z" level=info msg="not deleting local artifact" localArtPath=/tmp/argo/outputs/logs/main.log
time="2022-09-27T16:51:03.637Z" level=info msg="Successfully saved file: /tmp/argo/outputs/logs/main.log"
time="2022-09-27T16:51:03.661Z" level=info msg="Create workflowtaskresults 201"
time="2022-09-27T16:51:03.661Z" level=info msg="Deadline monitor stopped"
time="2022-09-27T16:51:03.661Z" level=info msg="stopping progress monitor (context done)" error="context canceled"
time="2022-09-27T16:51:03.661Z" level=info msg="Alloc=7571 TotalAlloc=15996 Sys=23506 NumGC=5 Goroutines=9"

Workflow Controller Log
time="2022-09-27T16:50:00.763Z" level=info msg="Processing workflow" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:50:00.776Z" level=info msg="Updated phase  -> Running" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:50:00.776Z" level=info msg="Steps node zargo-debug-child-qnxdn initialized Running" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:50:00.776Z" level=info msg="StepGroup node zargo-debug-child-qnxdn-2181329391 initialized Running" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:50:00.777Z" level=info msg="Pod node zargo-debug-child-qnxdn-1688663510 initialized Pending" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:50:00.809Z" level=info msg="Created pod: zargo-debug-child-qnxdn[0].node1 (zargo-debug-child-qnxdn-work-1688663510)" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:50:00.809Z" level=info msg="Workflow step group node zargo-debug-child-qnxdn-2181329391 not yet completed" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:50:00.809Z" level=info msg="TaskSet Reconciliation" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:50:00.809Z" level=info msg=reconcileAgentPod namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:50:00.820Z" level=info msg="Workflow update successful" namespace=argo phase=Running resourceVersion=10468680 workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:50:10.811Z" level=info msg="Processing workflow" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:50:10.811Z" level=info msg="Task-result reconciliation" namespace=argo numObjs=0 workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:50:10.811Z" level=info msg="node changed" namespace=argo new.message= new.phase=Running new.progress=0/1 nodeID=zargo-debug-child-qnxdn-1688663510 old.message= old.phase=Pending old.progress=0/1 workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:50:10.811Z" level=info msg="Workflow step group node zargo-debug-child-qnxdn-2181329391 not yet completed" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:50:10.811Z" level=info msg="TaskSet Reconciliation" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:50:10.811Z" level=info msg=reconcileAgentPod namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:50:10.824Z" level=info msg="Workflow update successful" namespace=argo phase=Running resourceVersion=10468732 workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:12.959Z" level=info msg="Processing workflow" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:12.959Z" level=info msg="Task-result reconciliation" namespace=argo numObjs=1 workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:12.959Z" level=info msg="task-result changed" namespace=argo nodeID=zargo-debug-child-qnxdn-1688663510 workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:12.960Z" level=info msg="node changed" namespace=argo new.message= new.phase=Succeeded new.progress=0/1 nodeID=zargo-debug-child-qnxdn-1688663510 old.message= old.phase=Running old.progress=0/1 workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:12.960Z" level=info msg="Step group node zargo-debug-child-qnxdn-2181329391 successful" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:12.960Z" level=info msg="node zargo-debug-child-qnxdn-2181329391 phase Running -> Succeeded" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:12.960Z" level=info msg="node zargo-debug-child-qnxdn-2181329391 finished: 2022-09-27 16:51:12.960547268 +0000 UTC" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:12.960Z" level=info msg="StepGroup node zargo-debug-child-qnxdn-2248586962 initialized Running" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:12.960Z" level=info msg="SG Outbound nodes of zargo-debug-child-qnxdn-1688663510 are [zargo-debug-child-qnxdn-1688663510]" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:12.961Z" level=info msg="Pod node zargo-debug-child-qnxdn-3431233478 initialized Pending" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:12.996Z" level=info msg="Created pod: zargo-debug-child-qnxdn[1].node2 (zargo-debug-child-qnxdn-work-3431233478)" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:12.996Z" level=info msg="Workflow step group node zargo-debug-child-qnxdn-2248586962 not yet completed" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:12.996Z" level=info msg="TaskSet Reconciliation" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:12.996Z" level=info msg=reconcileAgentPod namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:13.008Z" level=info msg="Workflow update successful" namespace=argo phase=Running resourceVersion=10469033 workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:13.013Z" level=info msg="cleaning up pod" action=labelPodCompleted key=argo/zargo-debug-child-qnxdn-work-1688663510/labelPodCompleted
time="2022-09-27T16:51:22.998Z" level=info msg="Processing workflow" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:22.998Z" level=info msg="Task-result reconciliation" namespace=argo numObjs=1 workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:22.998Z" level=info msg="node changed" namespace=argo new.message= new.phase=Running new.progress=0/1 nodeID=zargo-debug-child-qnxdn-3431233478 old.message= old.phase=Pending old.progress=0/1 workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:22.998Z" level=info msg="SG Outbound nodes of zargo-debug-child-qnxdn-1688663510 are [zargo-debug-child-qnxdn-1688663510]" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:22.998Z" level=info msg="Workflow step group node zargo-debug-child-qnxdn-2248586962 not yet completed" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:22.998Z" level=info msg="TaskSet Reconciliation" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:22.999Z" level=info msg=reconcileAgentPod namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:51:23.011Z" level=info msg="Workflow update successful" namespace=argo phase=Running resourceVersion=10469088 workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.256Z" level=info msg="Processing workflow" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.256Z" level=info msg="Task-result reconciliation" namespace=argo numObjs=2 workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.256Z" level=info msg="task-result changed" namespace=argo nodeID=zargo-debug-child-qnxdn-3431233478 workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.256Z" level=info msg="node changed" namespace=argo new.message= new.phase=Succeeded new.progress=0/1 nodeID=zargo-debug-child-qnxdn-3431233478 old.message= old.phase=Running old.progress=0/1 workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.256Z" level=info msg="SG Outbound nodes of zargo-debug-child-qnxdn-1688663510 are [zargo-debug-child-qnxdn-1688663510]" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.256Z" level=info msg="Step group node zargo-debug-child-qnxdn-2248586962 successful" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.256Z" level=info msg="node zargo-debug-child-qnxdn-2248586962 phase Running -> Succeeded" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.256Z" level=info msg="node zargo-debug-child-qnxdn-2248586962 finished: 2022-09-27 16:52:25.256890468 +0000 UTC" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.256Z" level=info msg="Outbound nodes of zargo-debug-child-qnxdn-3431233478 is [zargo-debug-child-qnxdn-3431233478]" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.256Z" level=info msg="Outbound nodes of zargo-debug-child-qnxdn is [zargo-debug-child-qnxdn-3431233478]" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.256Z" level=info msg="node zargo-debug-child-qnxdn phase Running -> Succeeded" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.256Z" level=info msg="node zargo-debug-child-qnxdn finished: 2022-09-27 16:52:25.256948516 +0000 UTC" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.256Z" level=info msg="Checking daemoned children of zargo-debug-child-qnxdn" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.256Z" level=info msg="TaskSet Reconciliation" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.256Z" level=info msg=reconcileAgentPod namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.256Z" level=info msg="Running OnExit handler: b72ca92baf93-exit-handler" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.257Z" level=info msg="Steps node zargo-debug-child-qnxdn-4154040042 initialized Running" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.257Z" level=info msg="StepGroup node zargo-debug-child-qnxdn-3486861020 initialized Running" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.257Z" level=info msg="Pod node zargo-debug-child-qnxdn-1717903073 initialized Pending" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.285Z" level=info msg="Created pod: zargo-debug-child-qnxdn.onExit[0].success (zargo-debug-child-qnxdn-b72ca92baf93-send-slack-1717903073)" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.285Z" level=info msg="Skipping zargo-debug-child-qnxdn.onExit[0].failure: when 'Succeeded != Succeeded' evaluated false" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.285Z" level=info msg="Skipped node zargo-debug-child-qnxdn-3455007452 initialized Skipped (message: when 'Succeeded != Succeeded' evaluated false)" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.285Z" level=info msg="Workflow step group node zargo-debug-child-qnxdn-3486861020 not yet completed" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.298Z" level=info msg="Workflow update successful" namespace=argo phase=Running resourceVersion=10469324 workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:25.304Z" level=info msg="cleaning up pod" action=labelPodCompleted key=argo/zargo-debug-child-qnxdn-work-3431233478/labelPodCompleted
time="2022-09-27T16:52:35.287Z" level=info msg="Processing workflow" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.288Z" level=info msg="Task-result reconciliation" namespace=argo numObjs=3 workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.288Z" level=info msg="task-result changed" namespace=argo nodeID=zargo-debug-child-qnxdn-1717903073 workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.288Z" level=info msg="node changed" namespace=argo new.message= new.phase=Succeeded new.progress=0/1 nodeID=zargo-debug-child-qnxdn-1717903073 old.message= old.phase=Pending old.progress=0/1 workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.288Z" level=info msg="TaskSet Reconciliation" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.288Z" level=info msg=reconcileAgentPod namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.288Z" level=info msg="Running OnExit handler: b72ca92baf93-exit-handler" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.288Z" level=info msg="Step group node zargo-debug-child-qnxdn-3486861020 successful" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.288Z" level=info msg="node zargo-debug-child-qnxdn-3486861020 phase Running -> Succeeded" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.288Z" level=info msg="node zargo-debug-child-qnxdn-3486861020 finished: 2022-09-27 16:52:35.288917456 +0000 UTC" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.288Z" level=info msg="Outbound nodes of zargo-debug-child-qnxdn-1717903073 is [zargo-debug-child-qnxdn-1717903073]" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.288Z" level=info msg="Outbound nodes of zargo-debug-child-qnxdn-3455007452 is [zargo-debug-child-qnxdn-3455007452]" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.288Z" level=info msg="Outbound nodes of zargo-debug-child-qnxdn-4154040042 is [zargo-debug-child-qnxdn-1717903073 zargo-debug-child-qnxdn-3455007452]" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.288Z" level=info msg="node zargo-debug-child-qnxdn-4154040042 phase Running -> Succeeded" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.288Z" level=info msg="node zargo-debug-child-qnxdn-4154040042 finished: 2022-09-27 16:52:35.288986789 +0000 UTC" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.288Z" level=info msg="Checking daemoned children of zargo-debug-child-qnxdn-4154040042" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.289Z" level=info msg="Updated phase Running -> Succeeded" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.289Z" level=info msg="Marking workflow completed" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.289Z" level=info msg="Marking workflow as pending archiving" namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.289Z" level=info msg="Checking daemoned children of " namespace=argo workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.294Z" level=info msg="cleaning up pod" action=deletePod key=argo/zargo-debug-child-qnxdn-1340600742-agent/deletePod
time="2022-09-27T16:52:35.301Z" level=info msg="Workflow update successful" namespace=argo phase=Succeeded resourceVersion=10469386 workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.515Z" level=info msg="archiving workflow" namespace=argo uid=6dceddd6-f757-4398-85e1-34333b8aaa13 workflow=zargo-debug-child-qnxdn
time="2022-09-27T16:52:35.520Z" level=info msg="cleaning up pod" action=labelPodCompleted key=argo/zargo-debug-child-qnxdn-b72ca92baf93-send-slack-1717903073/labelPodCompleted
time="2022-09-27T16:52:35.554Z" level=info msg="Queueing Succeeded workflow argo/zargo-debug-child-qnxdn for delete in 18h0m0s due to TTL"

@terrytangyuan Yes we are archiving workflows. But the problem here is that the workflow is not listed while it is running. Once the workflow transitions to a new node in the flow and the list of workflows in the UI is open while it does it will show in the list.

@scravy Can you check if a namespace filter is populated with the cookie's default value?

@sarabala1979 I am not sure what you mean by "the cookie's default value".
In the UI I do have a filter set for namespace = argo – but then again we do everything in that namespace and all workflows show up here, and it used to work in previous versions or argo, so not sure how this would affect anything.
I looked at the cookies and there's four cookies set: authorization, _ga_E659EW9J25, _gcl_au, and _ga.

It also happens to me.
When you first load the workflow page in the UI it does not show all the workflows available but if you wait like 20 or 30 seconds they suddenly appear. Access directly to the URL of a specific workflow works fine always, this only happen in the list view.
I'm not sure about the root cause but it seems more related to the UI than the server.

@scravy Is it working as expected on v3.3?

When I refresh the page it always show the list incomplete and after some time it loads all the workflows.
I noticed the issue is calling this endpoint:
https://argo/api/v1/workflow-events/argo-workflows?listOptions.fieldSelector=metadata.namespace=argo-workflows&fields=result.object.metadata.name,result.object.metadata.namespace,result.object.metadata.resourceVersion,result.object.metadata.creationTimestamp,result.object.metadata.uid,result.object.status.finishedAt,result.object.status.phase,result.object.status.message,result.object.status.startedAt,result.object.status.estimatedDuration,result.object.status.progress,result.type,result.object.metadata.labels,result.object.spec.suspend

As soon as this error appears in the browser console the UI loads all the workflows.

@terrytangyuan No, they do not appear when the list view is refreshed. On the contrary: When they appear and you then refresh they are gone again. Until the workflow transitions to a new node and pops up again.
@sarabala1979 We actually made a version jump from 3.1 where it used to work to 3.4 where it doesn't. I can try setting up a 3.3 later today and see whether the problem exists or not.
@ese On my installation I do not actually see any errors in the UI / dev console. As I mentioned above once a workflow event comes in the workflow is shown, but not all workflows. Are you sure all missing workflows are being shown once you hit that error?

Seeing the same issue.
After I enqueue some workflows (and while they stay in the "Pending" state), they are not initially displayed when I open the list view. After some time they appear (as "Pending"). If I refresh the page, they are gone again.
kubectl get workflow and argo list correctly show those disappearing workflows as Pending.
We upgraded from 3.3.8 to 3.4.1 recently.

I setup a 3.3 on our dev cluster and things work as expected. Both 3.4.0 and 3.4.1 show the regression as described here.

Bumping this issue. Also: https://drewdevault.com/2021/10/26/stalebot.html I do agree. This is an open source project. I am investing time in reporting and helping analyze this issue. And then I am told "you didn't fix this yourself, bugger off, we mark this as stale and will close/dismiss it eventually".

There is an error in your console, but I don’t see the diagnostics.
Can you please add any Argo Server logs that show more details.

Here are argo server logs from running the workflow which I showed in the beginning.
time="2022-12-20T11:19:18.594Z" level=info msg="not enabling pprof debug endpoints"
time="2022-12-20T11:19:18.594Z" level=info authModes="[sso client]" baseHRef=/ managedNamespace= namespace=argo secure=true ssoNamespace=argo
time="2022-12-20T11:19:18.594Z" level=info msg="Generating Self Signed TLS Certificates for Secure Mode"
time="2022-12-20T11:19:18.896Z" level=info msg="SSO configuration" clientId="{{google-oauth} client-id <nil>}" insecureSkipVerify=false issuer="https://accounts.google.com" issuerAlias=DISABLED redirectUrl="https://octoplane.incrmntal.net/oauth2/callback" scopes="[email openid]"
time="2022-12-20T11:19:18.997Z" level=info msg="SSO enabled"
time="2022-12-20T11:19:19.005Z" level=info msg="Starting Argo Server" instanceID= version=v3.4.4
time="2022-12-20T11:19:19.042Z" level=info msg="Creating event controller" asyncDispatch=false operationQueueSize=16 workerCount=4
time="2022-12-20T11:19:19.045Z" level=info msg="GRPC Server Max Message Size, MaxGRPCMessageSize, is set" GRPC_MESSAGE_SIZE=104857600
time="2022-12-20T11:19:19.045Z" level=info msg="Argo Server started successfully on https://localhost:2746" url="https://localhost:2746"
time="2022-12-20T11:19:36.723Z" level=info duration="79.831µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:37.998Z" level=info duration="59.801µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:39.022Z" level=info duration="67.497µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:39.574Z" level=info duration="67.56µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:39.575Z" level=info duration="51.682µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:39.575Z" level=info duration="250.961µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:39.579Z" level=info duration="43.963µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:39.579Z" level=info duration="60.938µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:39.579Z" level=info duration="64.415µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:39.579Z" level=info duration="54.907µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:39.784Z" level=info duration="84.558µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:39.785Z" level=info duration="52.762µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:39.825Z" level=info duration="53.165µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:40.404Z" level=info msg="using the default service account for user" email=REDACTED subject=REDACTED
time="2022-12-20T11:19:41.233Z" level=info msg="using the default service account for user" email=REDACTED subject=REDACTED
time="2022-12-20T11:19:41.283Z" level=info msg="using the default service account for user" email=REDACTED subject=REDACTED
time="2022-12-20T11:19:44.807Z" level=info msg="using the default service account for user" email=REDACTED subject=REDACTED
time="2022-12-20T11:19:45.483Z" level=info msg="using the default service account for user" email=REDACTED subject=REDACTED
time="2022-12-20T11:19:45.484Z" level=info msg="using the default service account for user" email=REDACTED subject=REDACTED
time="2022-12-20T11:19:46.796Z" level=info duration="78.009µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:47.060Z" level=info duration="61.868µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:48.360Z" level=info duration="81.547µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:48.893Z" level=info duration="60.056µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:49.057Z" level=info duration="78.274µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:49.086Z" level=info duration="92.317µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:49.562Z" level=info duration="76.271µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:49.582Z" level=info duration="59.7µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:49.620Z" level=info duration="93.988µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:49.621Z" level=info duration="48.601µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:49.678Z" level=info duration="71.587µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:49.678Z" level=info duration="50.859µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:49.705Z" level=info duration="65.62µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:49.723Z" level=info duration="65.859µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:50.408Z" level=info duration="76.328µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:51.366Z" level=info duration="72.342µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:53.001Z" level=info duration="84.05µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:54.024Z" level=info duration="62.148µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:54.581Z" level=info duration="65.373µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:54.581Z" level=info duration="45.289µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:54.581Z" level=info duration="71.962µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:54.581Z" level=info duration="40.367µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:54.581Z" level=info duration="54.945µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:54.581Z" level=info duration="58.917µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:54.581Z" level=info duration="40.969µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:54.782Z" level=info duration="66.14µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:54.787Z" level=info duration="55.769µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:54.809Z" level=info duration="63.441µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:56.723Z" level=info duration="63.826µs" method=GET path=index.html size=473 status=0
time="2022-12-20T11:19:57.654Z" level=info msg="using the default service account for user" email=REDACTED subject=REDACTED
time="2022-12-20T11:19:57.677Z" level=info msg="finished unary call with code OK" grpc.code=OK grpc.method=ResubmitWorkflow grpc.service=workflow.WorkflowService grpc.start_time="2022-12-20T11:19:57Z" grpc.time_ms=24.06 span.kind=server system=grpc
time="2022-12-20T11:19:57.678Z" level=info duration=25.971117ms method=PUT path=/api/v1/workflows/argo/zargo-debug-child/resubmit size=2591 status=0
time="2022-12-20T11:19:57.822Z" level=info duration=12.340447759s method=GET path=/api/v1/workflow-events/argo size=8594 status=0
time="2022-12-20T11:19:57.822Z" level=info msg="finished streaming call with code OK" grpc.code=OK grpc.method=WatchWorkflows grpc.service=workflow.WorkflowService grpc.start_time="2022-12-20T11:19:45Z" grpc.time_ms=12340.208 span.kind=server system=grpc
time="2022-12-20T11:19:57.835Z" level=info msg="using the default service account for user" email=REDACTED subject=REDACTED
time="2022-12-20T11:20:00.907Z" level=info duration="24.72µs" method=GET path=index.html size=0 status=304
time="2022-12-20T11:20:01.031Z" level=info duration=16.226099745s method=GET path=/api/v1/workflow-events/argo size=84524 status=0
time="2022-12-20T11:20:01.031Z" level=info msg="finished streaming call with code OK" grpc.code=OK grpc.method=WatchWorkflows grpc.service=workflow.WorkflowService grpc.start_time="2022-12-20T11:19:44Z" grpc.time_ms=16225.839 span.kind=server system=grpc
time="2022-12-20T11:20:01.471Z" level=info msg="using the default service account for user" email=REDACTED subject=<D-r>
time="2022-12-20T11:20:01.499Z" level=info msg="using the default service account for user" email=REDACTED subject=REDACTED
time="2022-12-20T11:20:01.499Z" level=info msg="tracking UI usage" email=REDACTED name=openedWorkflowList subject=REDACTED
time="2022-12-20T11:20:01.499Z" level=info msg="finished unary call with code OK" grpc.code=OK grpc.method=CollectEvent grpc.service=info.InfoService grpc.start_time="2022-12-20T11:20:01Z" grpc.time_ms=1.439 span.kind=server system=grpc
time="2022-12-20T11:20:01.499Z" level=info duration=30.505105ms method=POST path=/api/v1/tracking/event size=2 status=0
time="2022-12-20T11:20:01.575Z" level=info msg="using the default service account for user" email=REDACTED subject=REDACTED
time="2022-12-20T11:20:01.575Z" level=info msg="finished unary call with code OK" grpc.code=OK grpc.method=GetInfo grpc.service=info.InfoService grpc.start_time="2022-12-20T11:20:01Z" grpc.time_ms=1.503 span.kind=server system=grpc
time="2022-12-20T11:20:01.576Z" level=info duration=1.979622ms method=GET path=/api/v1/info size=67 status=0
time="2022-12-20T11:20:01.577Z" level=info msg="using the default service account for user" email=REDACTED subject=REDACTED
time="2022-12-20T11:20:01.577Z" level=info msg="finished unary call with code OK" grpc.code=OK grpc.method=GetUserInfo grpc.service=info.InfoService grpc.start_time="2022-12-20T11:20:01Z" grpc.time_ms=1.642 span.kind=server system=grpc
time="2022-12-20T11:20:01.577Z" level=info duration=2.005306ms method=GET path=/api/v1/userinfo size=110 status=0
time="2022-12-20T11:20:01.578Z" level=info msg="using the default service account for user" email=REDACTED subject=REDACTED
time="2022-12-20T11:20:01.613Z" level=info msg="finished unary call with code OK" grpc.code=OK grpc.method=ListCronWorkflows grpc.service=cronworkflow.CronWorkflowService grpc.start_time="2022-12-20T11:20:01Z" grpc.time_ms=36.216 span.kind=server system=grpc
time="2022-12-20T11:20:01.614Z" level=info msg="finished unary call with code OK" grpc.code=OK grpc.method=ListWorkflowTemplates grpc.service=workflowtemplate.WorkflowTemplateService grpc.start_time="2022-12-20T11:20:01Z" grpc.time_ms=143.616 span.kind=server system=grpc
time="2022-12-20T11:20:01.614Z" level=info duration=38.550003ms method=GET path=/api/v1/cron-workflows/argo size=26549 status=0
time="2022-12-20T11:20:01.706Z" level=info msg="using the default service account for user" email=REDACTED subject=REDACTED
time="2022-12-20T11:20:01.778Z" level=info duration=309.0362ms method=GET path=/api/v1/workflow-templates/argo size=1043014 status=0
time="2022-12-20T11:20:01.836Z" level=info msg="using the default service account for user" email=REDACTED subject=REDACTED

Since opening the ticket we upgraded to Argo 3.4.4 and the problem still persists.
Anything I can do to share more information with you? I was on sabbatical the past two months but can react quickly now.

I can confirm that this works as expected in 3.3.9 but not in 3.4.0

I dug into the (very large) changelog for 3.4.0-rc1 and the one thing that seemed potentially related to this is #8596, which added a date range filter to the UI. Specifically, this added a new default to the UI (this line) to only show the past month.
argo list meanwhile does not have such a default.
When you remove the date filter, does this still occur?
With the Workflow only appearing after a transition, that sounds it could be because one of the statuses does not yet exist. The UI seems to exclusively filter on status.startedAt. Meanwhile, the CLI filters on the metadata.creationTimestamp and status.finishedAt.
metadata.creationTimestamp may exist immediately, whereas status.startedAt may not, if I had to guess.
I may be able to fix the UI transition issue based on the above, but the CLI and UI having different defaults seems like it may be a bit unintuitive.

Looks like this may have been partially fixed by #9909 (released in 3.4.4) for Pending workflows specifically.

Was unable to reproduce on latest 3.5.0-rc1+. This seems like it was indeed fixed by #9909 as only a Pending workflow would have no status.startedAt.
We may want to remove the new default in 3.4.0+ of showing only last month first if users are confused by that. Then the UI would by default match the CLI as well. I'll leave that decision to more tenured contributors + maintainers to decide.
@terrytangyuan @sarabala1979 @alexec any thoughts on UI vs. CLI defaults as mentioned above?

Ok I did find a pretty bad bug in the date filtering logic: when either of the date filter were cleared, no Workflows would show, as they were comparing dates against undefined, which always result in false. 😬
I submitted a fix for this in #11792
That should only have impact if one of the date filters were clear, which was something I didn't test for when I tried repro'ing in my previous comment.

We may want to remove the new default in 3.4.0+ of showing only last month first if users are confused by that. Then the UI would by default match the CLI as well. I'll leave that decision to more tenured contributors + maintainers to decide.
@terrytangyuan @sarabala1979 @alexec any thoughts on UI vs. CLI defaults as mentioned above?

I've gone ahead and done this in #11840. With that PR, UI and CLI should now match.
The date filter is client-side, so it doesn't save on any networking to have a default and this issue and #11671 show that the current behavior is confusing and buggy. Hopefully that will all be cleared up now (although I was still unable to reproduce some of the bugs listed here and there).