(IOS) Offer Code Advice - Discussion

There isn't a discussion thread on this repo, so I just wanted to open something to have a running dialogue on Offer/Promo Codes with this package. I migrated my existing app from the CapGo plugin to this one and am now onto the phase of implementing promo codes for our application. On Android, it seems straightforward; set up promo codes in Google Play and have Google handle the rest natively with no code or UI changes, so to speak.
On the other hand IOS seems like a different beast. From the docs it seems like there are two ways to approach building a sign up flow UI that involves a promo code:
1.)Add UI that is along the lines of "Have a promo code" that is clickable
2.) Attach a listener for addCustomerInfoUpdateListener(...)
3.) Present the user with the redeemSheet using presentCodeRedemptionSheet()
4.) Listen for changes on CustomerInfo to see if the promo has been applied which would exist on the entitlements property
Other option:
1.) Add UI that is along the lines of "Have a promo code" that is clickable
2.) Collect the Promo code in the JS layer and dynamically build the appStore URL
3.) Attach a listener for Browser.addListener('browserFinished', () =>)
4.) Redirect the user to the appStore link using Browser.open
5.) On browser finish event call syncPurchase then look at the customerInfo to see if an active entitlement exists
Both of these seem like okay options, but I wanted to get opinions on best practices, as it seems that presentCodeRedemptionSheet is unstable at the Apple level. Another issue I am running into is that promo codes are not testable in a sandbox environment, so I would be looking for the best options to not only build the UI but test it to ensure it's stable before releasing to users.

Hey @aboedo. Appreciate the response. I did find the docs and figured that option 2 would be the best way to approach this feature. The last remaining issue is that it appears that promo codes are not able to be tested in sandbox environments on IOS. This seems like a pretty major hurdle as you would have to build an entire UI / signup flow and then send the app to production and just hope you got everything right? Is there a recommended approach on how to test the promo / offers codes using option 2 in a develop environment? Or even an approach where we could test in production without having external users able to access that feature in the app?

@danbunkr I have good news on that front!
For Option 1:
Apple recently shipped an update in Xcode Beta (well, at this point you can use the RC build), that allows you to set up Offer Codes for testing, and it should work correctly with RC. They have detailed instructions here: https://developer.apple.com/documentation/storekit/appstore/supporting_subscription_offer_codes_in_your_app#4281583
And here are the instructions to set up a StoreKit Configuration file with RevenueCat: https://www.revenuecat.com/docs/apple-app-store#step-1-add-a-storekit-configuration-file
For Option 2:
If offer codes work on Option 1, then they should work for Option 2, but obviously that's not a great answer in terms of testing. Truth is that testing Offer Codes has been nearly impossible for years and it's been our biggest complaint about the feature, even more so that the API's unreliable behavior.
One thought is that you could leverage Offerings Metadata as a way to set up a feature flag that you enable for yourself to test with in production. We're working on updating the docs for Capacitor for it, but it's available through offering.metadata.
Hope this helps!

@aboedo - That does help a lot thanks! Just to clarify you are saying I would need to be on Xcode 15 Beta (RC version) to test the offer codes locally?


Bento in-built pre-sizing layout pass support for multiline text.

Problem Statement
The BentoKit TitledDescription component would have a broken layout in the following scenarios, if we removed its manual sizing code:
TITLE         |
LINE2         |
--------------|     DETAIL
SUBTITLE      |
LINE2         |

Auto Layout apparently doesn't support these scenarios very well, as it produces an insufficient height of the cell that cannot fit all the vertical labels.
The common trick in layoutSubviews() alone also isn't applicable, since at that time AL would have already produced the cell size, and whatever preferredMaxLayoutWidth we change thereafter does not matter until the next time the UITableView invalidates its layout.
Solution
One solution is that we would do a two-pass layout — views that have multiline text may opt in by conforming to PresizingLayoutPassRequiring, so that Bento would trigger an extra layout pass before the AL cell sizing happens.
Then views containing multiline text labels can then update preferredMaxLayoutWidth of labels in layoutSubviews(), and being certain that the AL cell sizing happening thereafter would factor in the correct text rect height.
(Apparently UIKit has private APIs for it, and it is used in some unknown cases.)
If no view has specified this, Bento would not trigger a presizing layout pass.
Removing HeightCustomizing.
Since the primary use case of HeightCustomizing would be resolved by the introduction of RequiringPresizingLayoutPass, this PR removes also HeightCustomizing.
It may have impact upon scrolling experience in certain places, however, until #80 is deployed. Hence the Do Not Merge flag.
Other
The TitledDescription playground has been updated to reproduce the issue & illustrate that the issue is addressed by this new RequiringPresizingLayoutPass mechanism.

Before
After

Just an FYI that when this is merged, and when Babylon is updated to the latest master of Bento, there will be breaking changes for internal components that implement HeightCustomizing.

@mluisbrown Guess I should keep the protocol & just remove the conformance.

Did you run the BentoKit snapshot tests, to see if there are any changes?

Apple are cheaters

Can you provide the correct playground rather than reproduced one?

@inamiy Not sure what do you mean

Not sure what you mean exactly

Current TitledDescription.playground seems to show "Before" screen.
...But wait, I'm also seeing extension Component.TitledDescription.View: RequiringPreSizingLayoutPass which I first thought it was not implemented yet...
Am I missing something?

You need to use the updated playground on this branch, while removing HeightCustomizing conformance from TitledDescription to reveal the issue.

The scope of the PR has been reduced to just adding PresizingLayoutPassRequiring and updating TitledDescription.
It also removes the triggering in UICollectionViewReusableView and UICollectionViewCell, since Bento does not have sufficient knowledge in these views alone to trigger a presizing layout pass that leads to the expected outcome — it ultimately depends on the layout direction & sizing strategy.


repeat tests with TLS

Adding e2e tests when TLS is on

/hold

Waiting for #128

/retest

/retest

/unhold
seems ready


[rivers] add new port

[X] Changes comply with the maintainer guide
[X] The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.
[X] Optional dependencies are resolved in exactly one way. For example, if the component is built with CMake, all find_package calls are REQUIRED, are satisfied by vcpkg.json's declared dependencies, or disabled with CMAKE_DISABLE_FIND_PACKAGE_Xxx
[X] The versioning scheme in vcpkg.json matches what upstream says.
[X] The license declaration in vcpkg.json matches what upstream says.
[X] The installed as the "copyright" file matches what upstream says.
[X] The source code of the component installed comes from an authoritative source.
[X] The generated "usage text" is accurate. See adding-usage for context.
[X] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[X] Only one version is in the new port's versions file.
[X] Only one version is added to each modified port's versions file.

A formatter is provided for rivers under the header rivers/format.hpp. It presumes that <fmt/format.hpp> can be found as an include.

Maybe this need fmt.
https://github.com/brevzin/rivers#formatting

A formatter is provided for rivers under the header rivers/format.hpp. It presumes that <fmt/format.hpp> can be found as an include.

Maybe this need fmt. brevzin/rivers#formatting

I will add fmt as a feature.

This should be a default feature. :)


Integration tests for programmatic usage

If we consider that programmatic usage is an inherent feature of GuardDog, we should have tests for it.

Closing since programmatic usage isn't an officially supported feature. As of GuardDog v1.1.0 it's pretty trivial though, e.g. for local scanning:
from guarddog.scanners.pypi_package_scanner import PypiPackageScanner

scanner.scan_local(path)

Let's reconsider if programmatic usage is deemed useful


feat(Stylelint): Add stylelint config and presets WEB-990

Overview
Adds stylelint config package.
This will also work on styled-components.
PR Checklist

[ ] Related to Abstract designs:
[x] Related to JIRA ticket: WEB-990
[x] I have run this code to verify it works
[ ] This PR includes unit tests for the code change

Description

Adds @codecademy/stylelint-config npm package.
Based off of https://github.com/codecademy-engineering/Codecademy/blob/master/.stylelintrc
Adds 'stylelint-config-styled-components' to disable conflicting rules
Adds recommended VSCode extension: hex-ci.stylelint-plus (the one distributed by stylelint didn't seem to work out of the box, however, this does, happy to switch if people get the other one working easily).

Styled component config is basically just:
module.exports = {
  "rules": {
    "value-no-vendor-prefix": true,
    "property-no-vendor-prefix": true,
    "no-empty-source": null,
    "no-missing-end-of-source-newline": null
  }
}

Further work:

A full audit of the rules that we want.
Enable specific rulesets per package.
Replace usage on Monolith with a new package.
Add lint verification scripts and tasks if we are happy with the rulesets.
Deprecate SCSS lint?

📬Published Alpha Packages<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://5f358ccd404af374a2b43602--gamut-preview.netlify.appDeploy Logs


Fix typo in Index.js

@cssivision please accept pull request to fix typo in Index.js that is causing errors.


Instructions to trigger tests

There should be some documentation on how to trigger tests without having to wait for the nightly test run.

Done

Closed by https://github.com/econ-ark/DemARK/commit/ccec71c21a8b999336f0cc960276962a036c6bb8


remove ~&pure-mint from mint (prelude to jet decapitation)

This message printed on each recursion of mint:ut radically slows down the hoon code, and must be disabled if the hoon implementation is to take the place of the C.

Minor quibble, but is there any reason not to just delete the thing instead of commenting it out?  Generally I think it's good practice to be more aggressive than less when it comes to gutting dead code.


Using Agent.ToolsDirectory folder instead of Agent.WorkFolder

#80 Updated the Agent.WorkFolder to Agent.ToolsDirectory as the Agent.WorkFolder is not available in container jobs.

merged

Will work on this, when I come back from my holiday.
Meantime: If you read the documentation of MSFT: https://docs.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml#agent-variables
There is a Note for the Agent.WorkFolder variable:
"Note: This directory is not guaranteed to be writable by pipeline tasks (eg. when mapped into a container)"
and in our experience, this folder is not mapped to the build container instance.

Will work on this, when I come back from my holiday.
Meantime: If you read the documentation of MSFT: https://docs.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml#agent-variables
There is a Note for the Agent.WorkFolder variable:
"Note: This directory is not guaranteed to be writable by pipeline tasks (eg. when mapped into a container)"
and in our experience, this folder is not mapped to the build container instance.

This is exactly the issue our team ran into Error: EACCES: permission denied on linux in Azure Pipelines, we reverted to using an older version of this plugin/jfrog until this is fixed.

Same problem here. I had to run "sudo chmod 777 /__w/" as a workaround.
Is there any estimates about when will this fix be released?

1. Can you please elaborate about the use case causing this issue?  Shouldn't the 'Agent.WorkFolder' directory also be mounted?

I'm on Azure DevOps Server 2019 (on premise) and this is how it created my build container:
##[command]/bin/docker create --name xxx --label bf0b85 --network vsts_network_56b688da40424778a129ff1959fdfd30  -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/opt/vsts-agent1/_work/1":"/__w/1" -v "/opt/vsts-agent1/_work/_temp":"/__w/_temp" -v "/opt/vsts-agent1/_work/_tool":"/__t" -v "/opt/vsts-agent1/_work/_tasks":"/__w/_tasks" -v "/opt/vsts-agent1/externals":"/__a/externals":ro -v "/opt/vsts-agent1/_work/.taskkey":"/__w/.taskkey" myimage:xxx "/__a/externals/node/bin/node" -e "setInterval(function(){}, 24 * 60 * 60 * 1000);"
So, the "Agent.WorkFolder" wasn't mounted

@jeffrey-opdam -
@barbelity is attempting to resolve this issue in https://github.com/jfrog/artifactory-vsts-extension/pull/124

@jeffrey-opdam @rcsilva83 @d4rkd0s
We have release version 1.8.2 of the plugin, including a fix for this issue #125 .
Now, JFrog CLI is downloaded to the $(Agent.ToolsDirectory), which should solve the issue in container jobs.
Your feedback for that is highly appreciated!
I am closing this PR.


Support remote logging

We should support remote logging (so, for example, exceptions can be logged to servers for analysis)

This issue has been moved to dart-lang/logging#6.


Add Reboot and shutdown button to website

Reboot and shutdown the Pi over the web interface should be an option.
Thanks for the great work!

Shutdown is an option currently:

Shutdown is an option currently:

Oh sry i missed that


Work CI-CD

Description

Add task to install and run ngbv.
Add task to install and build required dependencies and packages.

Motivation and Context
How Has This Been Tested?

Screenshots
Types of changes

[ ] Improvement (non-breaking change that improves a feature, code or algorithm)
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[x] Config and build (change in the configuration and build system, has no impact on code or features)
[ ] Dependencies (update dependencies and changes associated, has no impact on code or features)
[ ] Unit Tests (work on Unit Tests, has no impact on code or features)
[ ] Documentation (changes or updates in the documentation, has no impact on code or features)

Checklist:

[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

@bart-jansen please check Discord when you have the time 😉


Inline potentially hot functions more aggressively

The functions when reading and writing using encase's wrappers can be very hot. #38 shows that these functions are not being inlined as aggressively. This PR attempts to coax the compiler doing so.
Full benchmark results:

Gnuplot not found, using plotters backend
Benchmarking Troughput/16KiB_write
Benchmarking Troughput/16KiB_write: Warming up for 3.0000 s
Benchmarking Troughput/16KiB_write: Collecting 100 samples in estimated 5.0075 s (1.9M iterations)
Benchmarking Troughput/16KiB_write: Analyzing
Troughput/16KiB_write   time:   [1.5729 µs 1.5746 µs 1.5763 µs]
                        thrpt:  [9.6799 GiB/s 9.6903 GiB/s 9.7013 GiB/s]
                 change:
                        time:   [-8.0639% -7.8170% -7.5969%] (p = 0.00 < 0.05)
                        thrpt:  [+8.2215% +8.4799% +8.7713%]
                        Performance has improved.
Found 5 outliers among 100 measurements (5.00%)
  2 (2.00%) low severe
  3 (3.00%) high mild
Benchmarking Troughput/16KiB_read
Benchmarking Troughput/16KiB_read: Warming up for 3.0000 s
Benchmarking Troughput/16KiB_read: Collecting 100 samples in estimated 5.0047 s (2.3M iterations)
Benchmarking Troughput/16KiB_read: Analyzing
Troughput/16KiB_read    time:   [1.0712 µs 1.0730 µs 1.0748 µs]
                        thrpt:  [14.197 GiB/s 14.221 GiB/s 14.244 GiB/s]
                 change:
                        time:   [-11.805% -11.044% -10.376%] (p = 0.00 < 0.05)
                        thrpt:  [+11.578% +12.415% +13.386%]
                        Performance has improved.
Found 4 outliers among 100 measurements (4.00%)
  4 (4.00%) low mild
Benchmarking Troughput/16KiB_create
Benchmarking Troughput/16KiB_create: Warming up for 3.0000 s
Benchmarking Troughput/16KiB_create: Collecting 100 samples in estimated 5.0085 s (1.5M iterations)
Benchmarking Troughput/16KiB_create: Analyzing
Troughput/16KiB_create  time:   [2.4438 µs 2.4495 µs 2.4545 µs]
                        thrpt:  [6.2166 GiB/s 6.2293 GiB/s 6.2439 GiB/s]
                 change:
                        time:   [-63.717% -63.466% -63.239%] (p = 0.00 < 0.05)
                        thrpt:  [+172.03% +173.72% +175.61%]
                        Performance has improved.
Found 7 outliers among 100 measurements (7.00%)
  3 (3.00%) low severe
  4 (4.00%) low mild
Benchmarking Troughput/16KiB_manual
Benchmarking Troughput/16KiB_manual: Warming up for 3.0000 s
Benchmarking Troughput/16KiB_manual: Collecting 100 samples in estimated 5.0078 s (3.0M iterations)
Benchmarking Troughput/16KiB_manual: Analyzing
Troughput/16KiB_manual  time:   [356.64 ns 357.51 ns 358.17 ns]
                        thrpt:  [42.602 GiB/s 42.681 GiB/s 42.785 GiB/s]
                 change:
                        time:   [-2.8350% -1.1837% +0.5988%] (p = 0.19 > 0.05)
                        thrpt:  [-0.5953% +1.1979% +2.9177%]
                        No change in performance detected.
Benchmarking Troughput/16KiB_stdlib
Benchmarking Troughput/16KiB_stdlib: Warming up for 3.0000 s
Benchmarking Troughput/16KiB_stdlib: Collecting 100 samples in estimated 5.0018 s (3.1M iterations)
Benchmarking Troughput/16KiB_stdlib: Analyzing
Troughput/16KiB_stdlib  time:   [379.93 ns 381.21 ns 382.13 ns]
                        thrpt:  [39.931 GiB/s 40.028 GiB/s 40.163 GiB/s]
                 change:
                        time:   [-2.7601% -0.1978% +2.5277%] (p = 0.89 > 0.05)
                        thrpt:  [-2.4654% +0.1982% +2.8384%]
                        No change in performance detected.
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) low mild
Benchmarking Troughput/128KiB_write
Benchmarking Troughput/128KiB_write: Warming up for 3.0000 s
Benchmarking Troughput/128KiB_write: Collecting 100 samples in estimated 5.0964 s (252k iterations)
Benchmarking Troughput/128KiB_write: Analyzing
Troughput/128KiB_write  time:   [12.469 µs 12.475 µs 12.482 µs]
                        thrpt:  [9.7800 GiB/s 9.7854 GiB/s 9.7902 GiB/s]
                 change:
                        time:   [-8.5845% -8.4567% -8.3377%] (p = 0.00 < 0.05)
                        thrpt:  [+9.0960% +9.2379% +9.3906%]
                        Performance has improved.
Found 5 outliers among 100 measurements (5.00%)
  1 (1.00%) low mild
  2 (2.00%) high mild
  2 (2.00%) high severe
Benchmarking Troughput/128KiB_read
Benchmarking Troughput/128KiB_read: Warming up for 3.0000 s
Benchmarking Troughput/128KiB_read: Collecting 100 samples in estimated 5.0326 s (323k iterations)
Benchmarking Troughput/128KiB_read: Analyzing
Troughput/128KiB_read   time:   [8.4088 µs 8.4427 µs 8.4746 µs]
                        thrpt:  [14.404 GiB/s 14.459 GiB/s 14.517 GiB/s]
                 change:
                        time:   [-14.693% -12.591% -10.795%] (p = 0.00 < 0.05)
                        thrpt:  [+12.102% +14.404% +17.223%]
                        Performance has improved.
Benchmarking Troughput/128KiB_create
Benchmarking Troughput/128KiB_create: Warming up for 3.0000 s
Benchmarking Troughput/128KiB_create: Collecting 100 samples in estimated 5.0483 s (207k iterations)
Benchmarking Troughput/128KiB_create: Analyzing
Troughput/128KiB_create time:   [16.998 µs 17.016 µs 17.034 µs]
                        thrpt:  [7.1665 GiB/s 7.1740 GiB/s 7.1815 GiB/s]
                 change:
                        time:   [-67.741% -67.671% -67.614%] (p = 0.00 < 0.05)
                        thrpt:  [+208.77% +209.32% +209.99%]
                        Performance has improved.
Found 16 outliers among 100 measurements (16.00%)
  12 (12.00%) low mild
  4 (4.00%) high mild
Benchmarking Troughput/128KiB_manual
Benchmarking Troughput/128KiB_manual: Warming up for 3.0000 s
Benchmarking Troughput/128KiB_manual: Collecting 100 samples in estimated 5.0282 s (439k iterations)
Benchmarking Troughput/128KiB_manual: Analyzing
Troughput/128KiB_manual time:   [2.6861 µs 2.6882 µs 2.6903 µs]
                        thrpt:  [45.374 GiB/s 45.410 GiB/s 45.446 GiB/s]
                 change:
                        time:   [-0.9956% +0.0743% +1.1614%] (p = 0.89 > 0.05)
                        thrpt:  [-1.1481% -0.0743% +1.0056%]
                        No change in performance detected.
Found 22 outliers among 100 measurements (22.00%)
  9 (9.00%) low severe
  13 (13.00%) low mild
Benchmarking Troughput/128KiB_stdlib
Benchmarking Troughput/128KiB_stdlib: Warming up for 3.0000 s
Benchmarking Troughput/128KiB_stdlib: Collecting 100 samples in estimated 5.0218 s (303k iterations)
Benchmarking Troughput/128KiB_stdlib: Analyzing
Troughput/128KiB_stdlib time:   [2.9594 µs 2.9727 µs 2.9827 µs]
                        thrpt:  [40.926 GiB/s 41.064 GiB/s 41.248 GiB/s]
                 change:
                        time:   [-3.8721% -1.7726% +0.2982%] (p = 0.10 > 0.05)
                        thrpt:  [-0.2973% +1.8046% +4.0281%]
                        No change in performance detected.
Benchmarking Troughput/1MiB_write
Benchmarking Troughput/1MiB_write: Warming up for 3.0000 s
Benchmarking Troughput/1MiB_write: Collecting 100 samples in estimated 5.2833 s (30k iterations)
Benchmarking Troughput/1MiB_write: Analyzing
Troughput/1MiB_write    time:   [116.57 µs 116.63 µs 116.70 µs]
                        thrpt:  [8.3683 GiB/s 8.3731 GiB/s 8.3774 GiB/s]
                 change:
                        time:   [-12.534% -12.325% -12.157%] (p = 0.00 < 0.05)
                        thrpt:  [+13.840% +14.058% +14.330%]
                        Performance has improved.
Found 8 outliers among 100 measurements (8.00%)
  1 (1.00%) low severe
  1 (1.00%) low mild
  2 (2.00%) high mild
  4 (4.00%) high severe
Benchmarking Troughput/1MiB_read
Benchmarking Troughput/1MiB_read: Warming up for 3.0000 s
Benchmarking Troughput/1MiB_read: Collecting 100 samples in estimated 5.2757 s (35k iterations)
Benchmarking Troughput/1MiB_read: Analyzing
Troughput/1MiB_read     time:   [94.258 µs 94.435 µs 94.643 µs]
                        thrpt:  [10.318 GiB/s 10.341 GiB/s 10.360 GiB/s]
                 change:
                        time:   [-6.8999% -6.5813% -6.2845%] (p = 0.00 < 0.05)
                        thrpt:  [+6.7059% +7.0450% +7.4113%]
                        Performance has improved.
Found 10 outliers among 100 measurements (10.00%)
  2 (2.00%) low mild
  3 (3.00%) high mild
  5 (5.00%) high severe
Benchmarking Troughput/1MiB_create
Benchmarking Troughput/1MiB_create: Warming up for 3.0000 s
Benchmarking Troughput/1MiB_create: Collecting 100 samples in estimated 5.1894 s (25k iterations)
Benchmarking Troughput/1MiB_create: Analyzing
Troughput/1MiB_create   time:   [154.30 µs 154.51 µs 154.76 µs]
                        thrpt:  [6.3103 GiB/s 6.3202 GiB/s 6.3291 GiB/s]
                 change:
                        time:   [-64.810% -64.757% -64.706%] (p = 0.00 < 0.05)
                        thrpt:  [+183.33% +183.74% +184.17%]
                        Performance has improved.
Found 5 outliers among 100 measurements (5.00%)
  1 (1.00%) low mild
  2 (2.00%) high mild
  2 (2.00%) high severe
Benchmarking Troughput/1MiB_manual
Benchmarking Troughput/1MiB_manual: Warming up for 3.0000 s
Benchmarking Troughput/1MiB_manual: Collecting 100 samples in estimated 5.4942 s (40k iterations)
Benchmarking Troughput/1MiB_manual: Analyzing
Troughput/1MiB_manual   time:   [55.898 µs 56.160 µs 56.522 µs]
                        thrpt:  [17.278 GiB/s 17.389 GiB/s 17.470 GiB/s]
                 change:
                        time:   [-4.0751% -3.1067% -2.2785%] (p = 0.00 < 0.05)
                        thrpt:  [+2.3316% +3.2063% +4.2482%]
                        Performance has improved.
Found 5 outliers among 100 measurements (5.00%)
  2 (2.00%) high mild
  3 (3.00%) high severe
Benchmarking Troughput/1MiB_stdlib
Benchmarking Troughput/1MiB_stdlib: Warming up for 3.0000 s
Benchmarking Troughput/1MiB_stdlib: Collecting 100 samples in estimated 5.3567 s (35k iterations)
Benchmarking Troughput/1MiB_stdlib: Analyzing
Troughput/1MiB_stdlib   time:   [78.908 µs 79.002 µs 79.100 µs]
                        thrpt:  [12.346 GiB/s 12.361 GiB/s 12.376 GiB/s]
                 change:
                        time:   [+8.2706% +8.7065% +9.0880%] (p = 0.00 < 0.05)
                        thrpt:  [-8.3309% -8.0092% -7.6388%]
                        Performance has regressed.
Found 11 outliers among 100 measurements (11.00%)
  3 (3.00%) low severe
  2 (2.00%) low mild
  4 (4.00%) high mild
  2 (2.00%) high severe
Benchmarking Troughput/16MiB_write
Benchmarking Troughput/16MiB_write: Warming up for 3.0000 s
Benchmarking Troughput/16MiB_write: Collecting 100 samples in estimated 5.1046 s (1700 iterations)
Benchmarking Troughput/16MiB_write: Analyzing
Troughput/16MiB_write   time:   [1.9566 ms 1.9629 ms 1.9704 ms]
                        thrpt:  [7.9299 GiB/s 7.9602 GiB/s 7.9857 GiB/s]
                 change:
                        time:   [-9.5856% -9.1602% -8.7316%] (p = 0.00 < 0.05)
                        thrpt:  [+9.5670% +10.084% +10.602%]
                        Performance has improved.
Found 11 outliers among 100 measurements (11.00%)
  2 (2.00%) high mild
  9 (9.00%) high severe
Benchmarking Troughput/16MiB_read
Benchmarking Troughput/16MiB_read: Warming up for 3.0000 s
Benchmarking Troughput/16MiB_read: Collecting 100 samples in estimated 5.0517 s (2000 iterations)
Benchmarking Troughput/16MiB_read: Analyzing
Troughput/16MiB_read    time:   [1.5998 ms 1.6033 ms 1.6074 ms]
                        thrpt:  [9.7208 GiB/s 9.7455 GiB/s 9.7666 GiB/s]
                 change:
                        time:   [-5.7922% -4.1732% -3.0456%] (p = 0.00 < 0.05)
                        thrpt:  [+3.1412% +4.3549% +6.1484%]
                        Performance has improved.
Found 3 outliers among 100 measurements (3.00%)
  3 (3.00%) high severe
Benchmarking Troughput/16MiB_create
Benchmarking Troughput/16MiB_create: Warming up for 3.0000 s
Benchmarking Troughput/16MiB_create: Collecting 100 samples in estimated 5.1876 s (1500 iterations)
Benchmarking Troughput/16MiB_create: Analyzing
Troughput/16MiB_create  time:   [2.5976 ms 2.6039 ms 2.6114 ms]
                        thrpt:  [5.9833 GiB/s 6.0006 GiB/s 6.0151 GiB/s]
                 change:
                        time:   [-63.189% -63.099% -62.987%] (p = 0.00 < 0.05)
                        thrpt:  [+170.17% +170.99% +171.66%]
                        Performance has improved.
Found 9 outliers among 100 measurements (9.00%)
  5 (5.00%) high mild
  4 (4.00%) high severe
Benchmarking Troughput/16MiB_manual
Benchmarking Troughput/16MiB_manual: Warming up for 3.0000 s
Benchmarking Troughput/16MiB_manual: Collecting 100 samples in estimated 5.0462 s (2100 iterations)
Benchmarking Troughput/16MiB_manual: Analyzing
Troughput/16MiB_manual  time:   [1.1353 ms 1.1425 ms 1.1508 ms]
                        thrpt:  [13.577 GiB/s 13.677 GiB/s 13.763 GiB/s]
                 change:
                        time:   [+15.028% +16.322% +17.589%] (p = 0.00 < 0.05)
                        thrpt:  [-14.958% -14.032% -13.065%]
                        Performance has regressed.
Found 6 outliers among 100 measurements (6.00%)
  3 (3.00%) high mild
  3 (3.00%) high severe
Benchmarking Troughput/16MiB_stdlib
Benchmarking Troughput/16MiB_stdlib: Warming up for 3.0000 s
Benchmarking Troughput/16MiB_stdlib: Collecting 100 samples in estimated 5.0448 s (1900 iterations)
Benchmarking Troughput/16MiB_stdlib: Analyzing
Troughput/16MiB_stdlib  time:   [1.3901 ms 1.3965 ms 1.4041 ms]
                        thrpt:  [11.128 GiB/s 11.189 GiB/s 11.240 GiB/s]
                 change:
                        time:   [-2.3783% -1.1699% +0.0554%] (p = 0.06 > 0.05)
                        thrpt:  [-0.0554% +1.1838% +2.4363%]
                        No change in performance detected.
Found 12 outliers among 100 measurements (12.00%)
  6 (6.00%) high mild
  6 (6.00%) high severe
Benchmarking Troughput/512MiB_write
Benchmarking Troughput/512MiB_write: Warming up for 3.0000 s

Warning: Unable to complete 100 samples in 5.0s. You may wish to increase target time to 19.1s, or reduce sample count to 20.
Benchmarking Troughput/512MiB_write: Collecting 100 samples in estimated 19.137 s (100 iterations)
Benchmarking Troughput/512MiB_write: Analyzing
Troughput/512MiB_write  time:   [105.70 ms 106.25 ms 107.17 ms]
                        thrpt:  [4.6656 GiB/s 4.7059 GiB/s 4.7305 GiB/s]
                 change:
                        time:   [-3.4867% -2.8708% -1.9544%] (p = 0.00 < 0.05)
                        thrpt:  [+1.9933% +2.9557% +3.6127%]
                        Performance has improved.
Found 6 outliers among 100 measurements (6.00%)
  3 (3.00%) high mild
  3 (3.00%) high severe
Benchmarking Troughput/512MiB_read
Benchmarking Troughput/512MiB_read: Warming up for 3.0000 s

Warning: Unable to complete 100 samples in 5.0s. You may wish to increase target time to 15.9s, or reduce sample count to 30.
Benchmarking Troughput/512MiB_read: Collecting 100 samples in estimated 15.917 s (100 iterations)
Benchmarking Troughput/512MiB_read: Analyzing
Troughput/512MiB_read   time:   [74.217 ms 74.329 ms 74.451 ms]
                        thrpt:  [6.7158 GiB/s 6.7268 GiB/s 6.7370 GiB/s]
                 change:
                        time:   [-6.1588% -5.7873% -5.4313%] (p = 0.00 < 0.05)
                        thrpt:  [+5.7432% +6.1428% +6.5630%]
                        Performance has improved.
Found 2 outliers among 100 measurements (2.00%)
  1 (1.00%) high mild
  1 (1.00%) high severe
Benchmarking Troughput/512MiB_create
Benchmarking Troughput/512MiB_create: Warming up for 3.0000 s

Warning: Unable to complete 100 samples in 5.0s. You may wish to increase target time to 19.0s, or reduce sample count to 20.
Benchmarking Troughput/512MiB_create: Collecting 100 samples in estimated 18.960 s (100 iterations)
Benchmarking Troughput/512MiB_create: Analyzing
Troughput/512MiB_create time:   [100.19 ms 102.03 ms 104.11 ms]
                        thrpt:  [4.8028 GiB/s 4.9007 GiB/s 4.9906 GiB/s]
                 change:
                        time:   [-60.347% -59.363% -58.254%] (p = 0.00 < 0.05)
                        thrpt:  [+139.54% +146.08% +152.19%]
                        Performance has improved.
Found 11 outliers among 100 measurements (11.00%)
  1 (1.00%) high mild
  10 (10.00%) high severe
Benchmarking Troughput/512MiB_manual
Benchmarking Troughput/512MiB_manual: Warming up for 3.0000 s

Warning: Unable to complete 100 samples in 5.0s. You may wish to increase target time to 16.0s, or reduce sample count to 30.
Benchmarking Troughput/512MiB_manual: Collecting 100 samples in estimated 15.993 s (100 iterations)
Benchmarking Troughput/512MiB_manual: Analyzing
Troughput/512MiB_manual time:   [44.600 ms 44.820 ms 45.094 ms]
                        thrpt:  [11.088 GiB/s 11.156 GiB/s 11.211 GiB/s]
                 change:
                        time:   [-3.9187% -2.6812% -1.4457%] (p = 0.00 < 0.05)
                        thrpt:  [+1.4669% +2.7551% +4.0785%]
                        Performance has improved.
Found 12 outliers among 100 measurements (12.00%)
  7 (7.00%) high mild
  5 (5.00%) high severe
Benchmarking Troughput/512MiB_stdlib
Benchmarking Troughput/512MiB_stdlib: Warming up for 3.0000 s

Warning: Unable to complete 100 samples in 5.0s. You may wish to increase target time to 14.1s, or reduce sample count to 30.
Benchmarking Troughput/512MiB_stdlib: Collecting 100 samples in estimated 14.084 s (100 iterations)
Benchmarking Troughput/512MiB_stdlib: Analyzing
Troughput/512MiB_stdlib time:   [28.370 ms 28.449 ms 28.539 ms]
                        thrpt:  [17.520 GiB/s 17.575 GiB/s 17.624 GiB/s]
                 change:
                        time:   [-4.1694% -3.0445% -2.0873%] (p = 0.00 < 0.05)
                        thrpt:  [+2.1318% +3.1401% +4.3509%]
                        Performance has improved.
Found 12 outliers among 100 measurements (12.00%)
  6 (6.00%) high mild
  6 (6.00%) high severe

It does seem like the create cases are over two times faster.

Not sure why but I can't seem to reproduce those improved numbers. For me, main and this PR produce the same numbers.
But if this improves perf on other people's machines, I see no downside here.


⚠ Mobitopup has degraded performance

In 9054cc2, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 4846 ms

Resolved: Mobitopup performance has improved in 3965cd9.


Fuel Codes | Adjust Feedstock and Finished fuel transport labels when adding or updating a fuel code |1|

https://trello.com/c/YtFHQUIH/1257-fuel-codes-adjust-feedstock-and-finished-fuel-transport-labels-when-adding-or-updating-a-fuel-code-1
Background Info:

IDIR user
New fuel code page (Administration tab > Fuel Codes > New Fuel Code)
When adding or updating a fuel code

Current labels:

Feedstock Transport Mode:
Finished Fuel Transport Mode:

Revised label:

Feedstock Transport Mode (use ctrl key to select multiple modes):
Finished Fuel Transport Mode:
Fuel Production Facility Nameplate Capacity (use ctrl key to select multiple modes):

 Fuel Codes | Adjust Feedstock and Finished fuel transport labels when adding or updating a fuel code |1|


Kafka Consumer rebalance not working correctly

Contact Details
No response
Version
8.x (develop, pre-release)
On which operating system(s) are you experiencing the issue?
Windows
Using which broker(s) did you encounter the issue?
Kafka
What are the steps required to reproduce the issue?
Hellow everyone!
We decided to use the Kafka broker as the main message broker along with MassTransit and decided to do some tests and noticed problem with topiс rebalance.
We created a topic with 2 partitions and launched 2 consumer services.

As a result, we observed:
1. if run Service1 and Service2 at the same time, Service1 is consuming from partition 0 and Service2 is consuming from partition 1. It's OK.
2. then if shutdown Service1 then Service2 will continue to consume from partition 0 and not consume from partitions 1
3. if Service1 is started again, no messages will be consumed from partition 0 (or 1)
4. sometimes when running two services at the same time, only one service consumes messages from a topics

For our tests we used Confluent Kafka Cloud free plan.

What is the expected behavior?
Group rebalancing done correctly for cases 2,3 and 4
What actually happened?
We don't understand yet whether this issue is a Kafka broker configuration or MassTransit configuration.
This is our test consumer (console app)
public static async Task Main()
    {
        var services = new ServiceCollection().AddLogging(builder =>
        {
            builder.AddConsole().SetMinimumLevel(LogLevel.Debug);
        });
        services.AddMassTransit(x =>
        {
            x.UsingInMemory();
            x.AddRider(rider =>
            {
                rider.AddConsumer<KafkaMessageConsumer>();
                rider.UsingKafka((context, k) =>
                {
                    k.Host("<host>", configurator =>
                    {
                        configurator.UseSasl(s =>
                        {
                            s.SecurityProtocol = SecurityProtocol.SaslSsl;
                            s.Mechanism = SaslMechanism.Plain;
                            s.Username = "name";
                            s.Password = "pwd";
                        });
                    });

                    k.ClientId = "client_1";
                    k.TopicEndpoint<string, TestMessage>("mt_test","test_group", e =>
                    {
                        e.AutoOffsetReset = AutoOffsetReset.Latest;
                        e.EnableAutoOffsetStore = true;
                        e.ConfigureConsumer<KafkaMessageConsumer>(context);
                        e.SetValueDeserializer(new MassTransitJsonDeserializer<TestMessage>());

                        // the number of concurrent messages, per partition
                        e.ConcurrentMessageLimit = 2;
                        // create up to two Confluent Kafka consumers, increases throughput with multiple partitions
                        e.ConcurrentConsumerLimit = 2;
                        // delivery only one message per key value within a partition at a time (default)
                        e.ConcurrentDeliveryLimit = 1;
                    });
                });
            });
        });
        var provider = services.BuildServiceProvider();
        var busControl = provider.GetRequiredService<IBusControl>();
        await busControl.StartAsync();
        Console.WriteLine("START");
        Console.ReadLine();
    }

public class TestMessage
{
    public string Text { get; init; }
}

class KafkaMessageConsumer : IConsumer<TestMessage>
{
    private readonly ILogger<KafkaMessageConsumer> _logger;

    public KafkaMessageConsumer(ILogger<KafkaMessageConsumer> logger)
    {
        _logger = logger;
    }

    public async Task Consume(ConsumeContext<TestMessage> msg)
    {
        _logger.LogInformation("Partition {0} Value {1}", msg.Partition(), msg.Message);
        await Task.Delay(3000);
    }
}

Related log output, including any exceptions
No response
Link to repository that demonstrates/reproduces the issue
No response

What EXACT version of MassTransit are you using? If you aren't on 8.0.10 or later, you need to upgrade.

I'd remove this, as MT takes care of checkpoint
e.EnableAutoOffsetStore = true;

this is set on your behalf by MT :)
e.SetValueDeserializer(new MassTransitJsonDeserializer<TestMessage>());

Another gap I can see, you have 2 partitions in total, and 2 services within 2 consumers. So, you have 4 consumers and 2 partitions, it might not rebalance at all, as you spin up 2 consumers on one instance, so 1 partition per consumer, right? Ideal scenario for kafka is to have 1 partition per consumer, it won't trigger rebalance:
e.ConcurrentConsumerLimit = 2;

@NooNameR Thank you for your advice. I'll try to answer consistently.
ClientId - rebalance does not work without this(
EnableAutoOffsetStore and SetValueDeserializer - yes), just for transparency
ConcurrentConsumerLimit  - the number of partitions is dynamic and we need to process a large number of messages in parallel, regardless of the number of partitions consumed by the service.
If we set ConcurrentConsumerLimit  = 1 all messages will be processed sequentially.
We also tried to set the minimum level of parallelism and this did not affect the result:
e.ConcurrentMessageLimit = 1;  e.ConcurrentConsumerLimit = 1;  e.ConcurrentDeliveryLimit = 1;
During testing, we also sometimes saw an error (Perhaps this is due to the work of MassTransit)
 MassTransit.ReceiveTransport[0]       [thrd:GroupCoordinator]: GroupCoordinator/6: Timed out LeaveGroupRequest in flight (after 5068ms, timeout #0): possibly held back by preceeding blocking JoinGroupRequest with timeout in 85527ms

the number of partitions is dynamic

this is clearly impossible, you define partitions count during topic creation, if you recreate topic as you go - it is gonna be a problem.
Long story short you don't need to have more consumers than partitions. Even having single consumer for all partitions is FINE, ConcurrentConsumerLimit is advance setting and mostly not needed when we are not talking thousands of partitions (and 10 instances, even tho by default it is gonna be fine)
MassTransit processing each topic-partition concurrently, you can play with ConcurrentMessageLimit. What is happening in you case, you have more consumers than partitions, so single service instance might own all of them. And just ensure you are using your keys wisely so it spreads across partitions.
fail: MassTransit[0]
      Partition: <out_topic> [[0]] checkpoint failed with offset: 624 on
      Confluent.Kafka.KafkaException: Broker: Unknown member
         at Confluent.Kafka.Impl.SafeKafkaHandle.Commit(IEnumerable`1 offsets)
         at Confluent.Kafka.Consumer`2.Commit(IEnumerable`1 offsets)
         at MassTransit.KafkaIntegration.Checkpoints.BatchCheckpointer.TryCheckpoint(IPendingConfirmation confirmation) in /_/src/Transports/MassTransit.KafkaIntegration/KafkaIntegration/Checkpoints/BatchCheckpointer.cs:line 147

Well it tells me that either topic got removed during consumption or your network is/was broken.

As for the error, I agree, most likely it is due to network errors
Regarding ConcurrentConsumersLimit
I ran some tests and saw a correlation between ConcurrentMessageLimit, ConcurrentConsumerLimit and partitions count. Your last comment says the same. And your approach is justified. But in  my opinion, this design have additional complexity.
one of the tests
partitions count = 2
ConcurrentMessageLimit = 1
ConcurrentConsumerLimit = 1

Observable behavior 1 (reproduced repeatedly)

start Service1: service started consuming from partition 0
start Service2: service didn't start consuming from partition 1
stop Service1: waiting for some time... Service2  service started consuming only from partition 0 but didn't start consuming from partition 1

Observable behavior 2 (reproduced repeatedly)

start Service1 and Service2 at the same time: Service1 consuming from partition 0 and  Service2 consuming from partition 1
stop Service1
Service2 continues to consume from partition 1.... and didn't start consuming from partition 0

...
Based on the test results, I came to the conclusion that I cannot use a high degree of parallelism for each  service.
In the example above, I cannot run two services, each of which will consume from one partition and process in parallel in several threads. Which will be very effective.
I can only start one service and configure a high degree of parallelism it to process messages  from several partitions. This is not efficient.
The same will happen if we have 6 partitions.
Three services will consume from two partitions and will be able to process a maximum of 2 messages in parallel. I can receive messages in a batch but I will have to add logic for parallel processing.

~What EXACT version of MassTransit are you using? If you aren't on 8.0.10 or later, you need to upgrade.~
I see you must be on 8.0.10, but knowing the specific version would be helpful.

We use 8.0.13 version

let's step back, a bit, can you enable logging in your application, redo behaviors and post the logs? it would help us to trace what's wrong.
Frankly speaking, we have test covering cross-partition cross-key producing.
So, without logs it would be hard to help...
(btw, you can try the same using docker locally just to exclude infrastructure setup)

let's step back, a bit, can you enable logging in your application, redo behaviors and post the logs?

100%. And if you're able to build a standalone repository with docker compose that demonstrates what you're seeing. You could use the MassTransit unit tests or even the Sample-Kafka project as a starting point. And we need full debugs logs that will show the partitions being assigned/revoked/etc. Because this has been tested and verified to properly rebalance as service instances are added/removed.

Without a solid reproducible repository that can consistently demonstrate this issue, it will be closed. Feel free to add a repository and re-open it if you're able to share something usable.

My apologies. didn't have time to respond quickly.
I created a small demo project and added docker-compose for local testing.
Consumer configuration
partitions count = 2
ConcurrentMessageLimit = 1
ConcurrentConsumerLimit = 1

1 - Run service instance 1 (dotnet run). We see that both partitions are assigned to one consumer, but messages are processed only from partition 0. Because ConcurrentConsumerLimit = 1 I think
[16:18:12 INF] Configured endpoint test_group, Consumer: KafkaConsumer.ReceivedConsumer
[16:18:12 DBG] Starting bus instances: IBus
[16:18:12 DBG] Starting bus: loopback://localhost/
[16:18:12 DBG] Endpoint Ready: loopback://localhost/DESKTOPRS6J28P_KafkaConsumer_bus_uybyyyn4ynrgcnr6bdptwz6kr9
[16:18:12 INF] Application started. Press Ctrl+C to shut down.
[16:18:12 INF] Hosting environment: Production
[16:18:12 INF] Content root path: ........\KafkaConsumer
[16:18:12 DBG] Endpoint Ready: loopback://localhost/kafka/test_topic/test_group
[16:18:12 INF] Bus started: loopback://localhost/
[16:18:15 DBG] Partition: test_topic [[0]] was assigned to: 48924c8d-1653-4f47-9e03-d700264d3131-2fe0871f-40e0-455a-9645-559b98629d6c
[16:18:15 DBG] Partition: test_topic [[1]] was assigned to: 48924c8d-1653-4f47-9e03-d700264d3131-2fe0871f-40e0-455a-9645-559b98629d6c
[16:18:16 INF] 18:16 Partition 0 - Message 83
[16:18:19 DBG] RECEIVE loopback://localhost/kafka/test_topic 1c480000-5a00-8866-c3c7-08db1a493124 Shared.Contracts.TestMessage KafkaConsumer.ReceivedConsumer(00:00:03.0040259)
[16:18:19 INF] 18:19 Partition 0 - Message 88
[16:18:22 DBG] RECEIVE loopback://localhost/kafka/test_topic 1c480000-5a00-8866-d88c-08db1a493130 Shared.Contracts.TestMessage KafkaConsumer.ReceivedConsumer(00:00:03.0122394)
[16:18:22 INF] 18:22 Partition 0 - Message 89
[16:18:25 DBG] RECEIVE loopback://localhost/kafka/test_topic 1c480000-5a00-8866-2e00-08db1a493133 Shared.Contracts.TestMessage KafkaConsumer.ReceivedConsumer(00:00:02.9927309)
[16:18:25 INF] 18:25 Partition 0 - Message 94
[16:18:28 DBG] RECEIVE loopback://localhost/kafka/test_topic 1c480000-5a00-8866-f004-08db1a49313e Shared.Contracts.TestMessage KafkaConsumer.ReceivedConsumer(00:00:03.0035209)

2 - run service instance 2.
Instance1 unsubscribed from partition 1 and continue processing from partition 0
[16:18:37 DBG] Partition: test_topic [[1]] was closed on 48924c8d-1653-4f47-9e03-d700264d3131-2fe0871f-40e0-455a-9645-559b98629d6c

Instance 2 - no messages from topic
[16:18:35 INF] Configured endpoint test_group, Consumer: KafkaConsumer.ReceivedConsumer
[16:18:35 DBG] Starting bus instances: IBus
[16:18:35 DBG] Starting bus: loopback://localhost/
[16:18:35 DBG] Endpoint Ready: loopback://localhost/DESKTOPRS6J28P_KafkaConsumer_bus_pyiyyyn4ynrgc8dzbdptwz6abw
[16:18:35 INF] Application started. Press Ctrl+C to shut down.
[16:18:35 INF] Hosting environment: Production
[16:18:35 INF] Content root path: .....\KafkaConsumer
[16:18:35 DBG] Endpoint Ready: loopback://localhost/kafka/test_topic/test_group
[16:18:35 INF] Bus started: loopback://localhost/

3 - stop instance 1 - instance 2 has subscribed to both topics and only consumes messages from topic 0.
[16:21:31 DBG] Partition: test_topic [[0]] was assigned to: 2d5b3f9c-2262-4d5e-864f-59a8ae0f9f14-052701a8-ef73-4779-aa38-a18f65f3119b
[16:21:31 DBG] Partition: test_topic [[1]] was assigned to: 2d5b3f9c-2262-4d5e-864f-59a8ae0f9f14-052701a8-ef73-4779-aa38-a18f65f3119b
[16:21:31 INF] 21:31 Partition 0 - Message 163
[16:21:34 DBG] RECEIVE loopback://localhost/kafka/test_topic 1c480000-5a00-8866-460a-08db1a4931e8 Shared.Contracts.TestMessage KafkaConsumer.ReceivedConsumer(00:00:03.0309137)
[16:21:34 INF] 21:34 Partition 0 - Message 168
[16:21:37 DBG] RECEIVE loopback://localhost/kafka/test_topic 1c480000-5a00-8866-80d1-08db1a4931f4 Shared.Contracts.TestMessage KafkaConsumer.ReceivedConsumer(00:00:03.0133187)
[16:21:37 INF] 21:37 Partition 0 - Message 169
[16:21:40 DBG] RECEIVE loopback://localhost/kafka/test_topic 1c480000-5a00-8866-e28d-08db1a4931f6 Shared.Contracts.TestMessage KafkaConsumer.ReceivedConsumer(00:00:03.0051107)
[16:21:40 INF] 21:40 Partition 0 - Message 174
[16:21:43 DBG] RECEIVE loopback://localhost/kafka/test_topic 1c480000-5a00-8866-9137-08db1a493204 Shared.Contracts.TestMessage KafkaConsumer.ReceivedConsumer(00:00:02.9974460)
[16:21:43 INF] 21:43 Partition 0 - Message 175
[16:21:46 DBG] RECEIVE loopback://localhost/kafka/test_topic 1c480000-5a00-8866-085a-08db1a493207 Shared.Contracts.TestMessage KafkaConsumer.ReceivedConsumer(00:00:03.0070022)
[16:21:46 INF] 21:46 Partition 0 - Message 176

Expected behavior:
If we have two topic partition, then two service instances consume messages each from their section at the same time.

your consumer just slow, so there is always a message inside "current" reading partition, confluent consumer will jump to next when it is done with current (that's how it works and we have 0 influence on that).
You did a delay on consumer which means "long-working" consumer, so basically you overwhelming single partition with messages.
When you start new instance it is taking some time to un-assign partition from consumer, it is configurable but I can't tell you off top of my head.
Increasing e.ConcurrentMessageLimit = 1000; just solving everything.
instance1_1.log
instance2_1.log
So, there is NOTHING wrong with kafka client, it is just how you configured your consumer and producer.
There is no term "consumer lag", when you produce more messages than your consumer throughput. (https://www.acceldata.io/blog/understanding-lag-in-kafka-cluster)
Adding additional 1sec delay (which is still less than consumer's) between producing messages in your producer. It works flawlessly.
instance1_2.log
instance2_2.log

if you need additional help how to use kafka corresponding to your particular case there is commercial support: https://masstransit.io/support

I agree with you, an increase ConcurrentMessageLimit led to the desired result.
Thanks you for the help :)


Wrong gist name on main.yml for PIC18F4550

Template was left as $gistTitle

Fixed issue with the gistTitle name, however the Gist itself has more than one file now, so this issue remains open until that is fixed


[MOD CHANGE] FMT_MEC_EXT.1/Server ECD doesn't match SFR

What is the change request for the Module and which module does this apply? Please describe.
The ECD for this SFR does not match the text of the requirement in the main body of the document. I think the one on the body is correct, but am not certain (and hence am not providing a pull request).
Describe the solution you'd like
correct the mismatch

Change implemented.


@types/jquery gave error

Bug Report or Feature Request (mark with an x)
- [x ] bug report -> please search issues before submitting
- [ ] feature request

Command (mark with an x)
- [ ] new
- [ ] build
- [x ] serve
- [ ] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc

Versions

node --version v10.13.0
npm --version 6.4.1
ng --version
Angular CLI: 7.0.6
Node: 10.13.0
OS: win32 x64
Angular: 7.1.0
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router
Package                           Version
@angular-devkit/architect         0.6.8
@angular-devkit/build-angular     0.6.8
@angular-devkit/build-optimizer   0.6.8
@angular-devkit/core              0.6.8
@angular-devkit/schematics        7.0.6
@angular/cli                      7.0.6
@ngtools/webpack                  6.0.8
@schematics/angular               7.0.6
@schematics/update                0.10.6
rxjs                              6.3.3
typescript                        3.1.6
webpack                           4.8.3
Repro steps

The log given by the failure

ERROR in node_modules/@types/jquery/index.d.ts(6316,66): error TS2344: Type '"timeout" | "onreadystatechange" | "responseType" | "withCredentials" | "msCaching"' does not satisfy the constraint '"abort" | "open" | "timeout" | "response" | "getAllResponseHeaders" | "getResponseHeader" | "overrideMimeType" | "readyState" | "responseText" | "setRequestHeader" | "status" | ... 22 more ... | "dispatchEvent"'.
Type '"msCaching"' is not assignable to type '"abort" | "open" | "timeout" | "response" | "getAllResponseHeaders" | "getResponseHeader" | "overrideMimeType" | "readyState" | "responseText" | "setRequestHeader" | "status" | ... 22 more ... | "dispatchEvent"'.
Desired functionality

Mention any other details that might be useful

I think this issue is not related to angular-cli. Check your code, it look like you have an issue your jQuery code.

Hello, we reviewed this issue and determined that it doesn't fall into the bug report or feature request category. This issue tracker is not suitable for support requests, please repost your issue on StackOverflow using tag angular-cli.
If you are wondering why we don't resolve support issues via the issue tracker, please check out this explanation.


Recorder Snapshot Test Is Super Flaky

It is almost always this test failure that blocks the new PR. Please fix.
To reproduce locally (use tsan because it slows everything down, and the UT may contain some wrong timing assumptions, so the UT fails more often under tsan):
$ i=0; while bazel test --config=prof --config=tsan --nocache_test_results --test_output=errors //tests:recorder_snapshot_test; do ((i=i+1)); printf "Test round %d passed.\n" $i; done; ((i=i+1)); printf "Test round %d FAILED.\n" $i

...

FAIL: //tests:recorder_snapshot_test (see /home/chenhao/.cache/bazel/_bazel_chenhao/dd7b92a42201a8d2f5ee22f4696125c0/execroot/cris-core/bazel-out/k8-opt/testlogs/tests/recorder_snapshot_test/test.log)
INFO: From Testing //tests:recorder_snapshot_test:
==================== Test output for //tests:recorder_snapshot_test:
Running main() from tests/utils/cris_gtest_main.cc
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from RecorderSnapshotTest
[ RUN      ] RecorderSnapshotTest.RecorderSnapshotTest
WARNING: Logging before InitGoogleLogging() is written to STDERR
I20230221 05:36:45.982210    12 job_runner.cc:220] JobRunner: JobRunner at 0x7b1400000050 initialized with 4 worker(s). 0 of them always stay active, others go to sleep if stay idle for more than 0 ms.
I20230221 05:36:46.014969    12 node.cc:19] CRNode: Binding node "cris::core::MessageRecorder"(at 0x7fff8ec1ba98) to runner at 0x7b1400000050
I20230221 05:36:46.038836    12 node.cc:14] CRNode: Node "noname"(at 0x7fff8ec1ba08) binds with no runner.
I20230221 05:36:50.792191    12 node.cc:14] CRNode: Node "cris::core::MessageReplayer"(at 0x7fff8ec1b898) binds with no runner.
I20230221 05:36:50.792414    12 node.cc:19] CRNode: Binding node "noname"(at 0x7fff8ec1b808) to runner at 0x7b1400000050
I20230221 05:36:50.839169    12 record_file.cc:100] Record "/tmp/CRSnapshotTestTmpDir.12/snapshots/1 SECOND/20230221-053646.022708721.UTC
/cris__core__TestMessage_subid_11.ldb.d" is empty, removing.
I20230221 05:36:50.839771    12 node.cc:14] CRNode: Node "cris::core::MessageReplayer"(at 0x7fff8ec1b898) binds with no runner.
I20230221 05:36:50.839854    12 node.cc:19] CRNode: Binding node "noname"(at 0x7fff8ec1b808) to runner at 0x7b1400000050
I20230221 05:36:50.864156    12 node.cc:14] CRNode: Node "cris::core::MessageReplayer"(at 0x7fff8ec1b898) binds with no runner.
I20230221 05:36:50.864231    12 node.cc:19] CRNode: Binding node "noname"(at 0x7fff8ec1b808) to runner at 0x7b1400000050
I20230221 05:36:50.885557    12 node.cc:14] CRNode: Node "cris::core::MessageReplayer"(at 0x7fff8ec1b898) binds with no runner.
I20230221 05:36:50.885641    12 node.cc:19] CRNode: Binding node "noname"(at 0x7fff8ec1b808) to runner at 0x7b1400000050
I20230221 05:36:50.912001    12 node.cc:14] CRNode: Node "cris::core::MessageReplayer"(at 0x7fff8ec1b898) binds with no runner.
I20230221 05:36:50.912084    12 node.cc:19] CRNode: Binding node "noname"(at 0x7fff8ec1b808) to runner at 0x7b1400000050
I20230221 05:36:50.941325    12 node.cc:14] CRNode: Node "cris::core::MessageReplayer"(at 0x7fff8ec1b898) binds with no runner.
I20230221 05:36:50.941427    12 node.cc:19] CRNode: Binding node "noname"(at 0x7fff8ec1b808) to runner at 0x7b1400000050
I20230221 05:36:50.965327    12 node.cc:14] CRNode: Node "cris::core::MessageReplayer"(at 0x7fff8ec1b898) binds with no runner.
I20230221 05:36:50.965422    12 node.cc:19] CRNode: Binding node "noname"(at 0x7fff8ec1b808) to runner at 0x7b1400000050
I20230221 05:36:50.988485    12 node.cc:14] CRNode: Node "cris::core::MessageReplayer"(at 0x7fff8ec1b898) binds with no runner.
I20230221 05:36:50.988571    12 node.cc:19] CRNode: Binding node "noname"(at 0x7fff8ec1b808) to runner at 0x7b1400000050
I20230221 05:36:51.014964    12 node.cc:14] CRNode: Node "cris::core::MessageReplayer"(at 0x7fff8ec1b898) binds with no runner.
I20230221 05:36:51.015071    12 node.cc:19] CRNode: Binding node "noname"(at 0x7fff8ec1b808) to runner at 0x7b1400000050
tests/recorder_snapshot_test.cc:200: Failure
Expected equality of these values:
  snapshot_dirs.size()
    Which is: 1
  kExpectedSnapshotNum
    Which is: 2
[  FAILED  ] RecorderSnapshotTest.RecorderSnapshotTest (5097 ms)
[----------] 1 test from RecorderSnapshotTest (5097 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (5097 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] RecorderSnapshotTest.RecorderSnapshotTest

 1 FAILED TEST
================================================================================
Target //tests:recorder_snapshot_test up-to-date:
  bazel-bin/tests/recorder_snapshot_test
INFO: Elapsed time: 7.483s, Critical Path: 7.20s
INFO: 2 processes: 1 internal, 1 linux-sandbox.
INFO: Build completed, 1 test FAILED, 2 total actions
//tests:recorder_snapshot_test                                           FAILED in 7.2s
  /home/chenhao/.cache/bazel/_bazel_chenhao/dd7b92a42201a8d2f5ee22f4696125c0/execroot/cris-core/bazel-out/k8-opt/testlogs/tests/recorder_snapshot_test/test.log

Executed 1 out of 1 test: 1 fails locally.
Test round 8 FAILED.

Please make sure it consistently passes, instead of failing every a few rounds. (Maybe run it a few hours without seeing any failure before declaring victory).

Add one more today:

https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1963

==================== Test output for //tests:recorder_snapshot_test:
[1919](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1920)
Running main() from tests/utils/cris_gtest_main.cc
[1920](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1921)
[==========] Running 1 test from 1 test case.
[1921](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1922)
[----------] Global test environment set-up.
[1922](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1923)
[----------] 1 test from RecorderSnapshotTest
[1923](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1924)
[ RUN      ] RecorderSnapshotTest.RecorderSnapshotTest
[1924](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1925)
WARNING: Logging before InitGoogleLogging() is written to STDERR
[1925](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1926)
I20230223 13:49:11.688699  2388 job_runner.cc:220] JobRunner: JobRunner at 0x7b1400000050 initialized with 4 worker(s). 0 of them always stay active, others go to sleep if stay idle for more than 0 ms.
[1926](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1927)
I20230223 13:49:11.731812  2388 node.cc:19] CRNode: Binding node "cris::core::MessageRecorder"(at 0x7ffc1f120688) to runner at 0x7b1400000050
[1927](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1928)
E20230223 13:49:11.741487  2419 recorder.cc:158] GenerateSnapshotImpl: Failed to copy record directory "/tmp/CRSnapshotTestTmpDir.2388/record.20230223-134911.UTC.pid.2388" to snapshot directory "/tmp/CRSnapshotTestTmpDir.2388/snapshots/1 SECOND/20230223-134911.740874628.UTC
[1928](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1929)
". No such file or directory
[1929](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1930)
I20230223 13:49:11.750682  2388 node.cc:14] CRNode: Node "noname"(at 0x7ffc1f1205f8) binds with no runner.
[1930](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1931)
I20230223 13:49:16.251559  2388 node.cc:14] CRNode: Node "cris::core::MessageReplayer"(at 0x7ffc1f120488) binds with no runner.
[1931](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1932)
I20230223 13:49:16.251674  2388 node.cc:19] CRNode: Binding node "noname"(at 0x7ffc1f1203f8) to runner at 0x7b1400000050
[1932](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1933)
tests/recorder_snapshot_test.cc:188: Failure
[1933](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1934)
Expected: (last_recorded) <= (0 + kFlakyTolerance), actual: 9 vs 2
[1934](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1935)
I20230223 13:49:16.266996  2388 node.cc:14] CRNode: Node "cris::core::MessageReplayer"(at 0x7ffc1f120488) binds with no runner.
[1935](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1936)
I20230223 13:49:16.267079  2388 node.cc:19] CRNode: Binding node "noname"(at 0x7ffc1f1203f8) to runner at 0x7b1400000050
[1936](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1937)
tests/recorder_snapshot_test.cc:194: Failure
[1937](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1938)
Expected: (last_recorded) <= (expect_num_end_with + kFlakyTolerance), actual: 19 vs 12
[1938](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1939)
I20230223 13:49:16.278039  2388 node.cc:14] CRNode: Node "cris::core::MessageReplayer"(at 0x7ffc1f120488) binds with no runner.
[1939](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1940)
I20230223 13:49:16.278098  2388 node.cc:19] CRNode: Binding node "noname"(at 0x7ffc1f1203f8) to runner at 0x7b1400000050
[1940](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1941)
tests/recorder_snapshot_test.cc:194: Failure
[1941](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1942)
Expected: (last_recorded) <= (expect_num_end_with + kFlakyTolerance), actual: 29 vs 22
[1942](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1943)
I20230223 13:49:16.989799  2388 node.cc:14] CRNode: Node "cris::core::MessageReplayer"(at 0x7ffc1f120488) binds with no runner.
[1943](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1944)
I20230223 13:49:16.989888  2388 node.cc:19] CRNode: Binding node "noname"(at 0x7ffc1f1203f8) to runner at 0x7b1400000050
[1944](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1945)
tests/recorder_snapshot_test.cc:194: Failure
[1945](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1946)
Expected: (last_recorded) <= (expect_num_end_with + kFlakyTolerance), actual: 39 vs 32
[1946](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1947)
tests/recorder_snapshot_test.cc:200: Failure
[1947](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1948)
Expected equality of these values:
[1948](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1949)
  snapshot_dirs.size()
[1949](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1950)
    Which is: 4
[1950](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1951)
  kExpectedSnapshotNum
[1951](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1952)
    Which is: 5
[1952](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1953)
I20230223 13:49:17.003873  2388 node.cc:14] CRNode: Node "cris::core::MessageReplayer"(at 0x7ffc1f120488) binds with no runner.
[1953](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1954)
I20230223 13:49:17.003927  2388 node.cc:19] CRNode: Binding node "noname"(at 0x7ffc1f1203f8) to runner at 0x7b1400000050
[1954](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1955)
I20230223 13:49:17.014524  2388 node.cc:14] CRNode: Node "cris::core::MessageReplayer"(at 0x7ffc1f120488) binds with no runner.
[1955](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1956)
I20230223 13:49:17.014611  2388 node.cc:19] CRNode: Binding node "noname"(at 0x7ffc1f1203f8) to runner at 0x7b1400000050
[1956](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1957)
I20230223 13:49:17.024629  2388 node.cc:14] CRNode: Node "cris::core::MessageReplayer"(at 0x7ffc1f120488) binds with no runner.
[1957](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1958)
I20230223 13:49:17.024691  2388 node.cc:19] CRNode: Binding node "noname"(at 0x7ffc1f1203f8) to runner at 0x7b1400000050
[1958](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1959)
I20230223 13:49:17.035616  2388 node.cc:14] CRNode: Node "cris::core::MessageReplayer"(at 0x7ffc1f120488) binds with no runner.
[1959](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1960)
I20230223 13:49:17.035706  2388 node.cc:19] CRNode: Binding node "noname"(at 0x7ffc1f1203f8) to runner at 0x7b1400000050
[1960](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1961)
I20230223 13:49:17.045934  2388 node.cc:14] CRNode: Node "cris::core::MessageReplayer"(at 0x7ffc1f120488) binds with no runner.
[1961](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1962)
I20230223 13:49:17.045994  2388 node.cc:19] CRNode: Binding node "noname"(at 0x7ffc1f1203f8) to runner at 0x7b1400000050
[1962](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1963)
[  FAILED  ] RecorderSnapshotTest.RecorderSnapshotTest (5396 ms)
[1963](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1964)
[----------] 1 test from RecorderSnapshotTest (5396 ms total)
[1964](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1965)

[1965](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1966)
[----------] Global test environment tear-down
[1966](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1967)
[==========] 1 test from 1 test case ran. (5396 ms total)
[1967](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1968)
[  PASSED  ] 0 tests.
[1968](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1969)
[  FAILED  ] 1 test, listed below:
[1969](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1970)
[  FAILED  ] RecorderSnapshotTest.RecorderSnapshotTest
[1970](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1971)

[1971](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1972)
 1 FAILED TEST
[1972](https://github.com/cyfitech/cris-core/actions/runs/4253243645/jobs/7397848784#step:5:1973)
================================================================================

另一个我在意的地方是，这里多了个回车？


Mute, random and repeat buttons are barely visible when using the day theme

As seen on the screenshots above, the mute, random and repeat buttons are barely visible on the day theme, probably because they are white on light background, instead of grey on white that the playback (stop, play etc) buttons are. Night theme has them all white on dark background, so no problem there.
Tested on android 4.3 with kore 2.3.2. I did not check how they looks on the other 2 themes.

The same problem applies to the solarized theme as well, but not on the mist one (screenshots added)

Thanks for reporting this. This seems to be an issue for devices running pre-Lollipop version of Android.

Yeah, android:tint isn't being applied.
There's something even stranger on the screenshots posted: where is the overflow button (the three dots)? I've tested this on 4.3 and at least it shows (with the correct color).

Which 3 dots do you mean? I may have disabled them in options, but there are 3 dots in the top right corner on every screenshot.

Ignore my comment. The screenshot is showing a music playing so the button isn't available, only on videos. My bad.

Actually is a web radio playlist on all screenshots :)