[BUG] iOS 15 - didReceiveRemoteNotification not called on background of first install

Describe the bug
A clear and concise description of what the bug is.
On iOS 15, when fresh install the app -> put it in background (not killed yet) -> send a notification to the app -> tap on the notification -> didReceiveRemoteNotification not called to handle the notification.
Exception or Stack Trace
Add the exception log and stack trace if available
To Reproduce
Steps to reproduce the behavior:
1/ Fresh install app
2/ Put it in background (not killed)
3/ Send notification to the app
4/ Tap on the notification
5/ didReceiveRemoteNotification method not called
Expected behavior
A clear and concise description of what you expected to happen.
didReceiveRemoteNotification is called to handle the notification
Setup (please complete the following information):

OS: iOS 15
IDE : Xcode 13
Version: 3.15

Additional context
Add any other context about the problem here.
Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[ x] Bug Description Added
[ x] Repro Steps Added
[ x] Setup information Added

@lucaschiem Do you find a solution ?


Add init methods to TagListView to resolve IBDesignable issues

Added initializers "required" for IBDesignables to the TagListView.
Fixes #71,  #123

👍 Thank you!


Signed-off-by: Timothy St. Clair<EMAIL_ADDRESS>/cc @liztio

:+1:


Fix(react): video.js type errors

Pins @types/video.js to a specific patch version. Fixes #902
@GGKapanadze, could you have a look at this? I started getting type errors when trying to build the React package. Pinning the types file to this version seemed to fix it.

@justintemps The type check for the react package doesn't reveal any errors and it also builds correctly.


Extension fails retrieve PR description from an enterprise repo and throws failed execute git error on vscode

Until version 0.78.1 of the extension there was issue viewing the PR description in VSCode for any repos. With 0.80.0 and above it fails to retrieve the information from an enterprise/org repo and throws 'failed execute git' error.  The output log doesn't have information in it to see what went wrong.
output log:
<FolderRepositoryManager+0> Found GitHub repo for pr #35308: yes
2024-02-12 07:11:18.390 [info] FolderRepositoryManager+0> Found GitHub pr repo for pr #35308: yes
2024-02-12 07:11:18.390 [info] GitHubRepository> Fetch branch main - enter
2024-02-12 07:11:18.693 [info] GitHubRepository> Fetch branch main - done: true

Extension version: 0.80.0 and above
VSCode Version: 1.86.1
OS: Windows 64 bit
Repository Clone Configuration (single repository/fork of an upstream repository): fork of an upstream repo
Github Product (Github.com/Github Enterprise version x.x.x): git version 2.43.0.windows.1

same as #5744
Resolved after signing out and signing back in.

Signing out and back in doesn't fix it for me.
I've tried that in multiple ways, in addition to reinstalling the extension.
Still failed to execute git every time when trying to open the description of a PR.

I have this issue as well. Possible issue - our organization has an enterprise co-pilot program, I'm logged into VS Code with both my personal and enterprise account.


[SR-5823] ISO8601 DateFormatter/Codeable incomplete

Previous ID
SR-5823

Radar
rdar://problem/32755663

Original Reporter
FGoessler (JIRA User)

Type
Bug

Additional Detail from JIRA

Votes
4

Component/s
Foundation

Labels
Bug

Assignee
@itaiferber

Priority
Medium

md5: 6cc2a18bb37f3c5b8856aeac7a543bba

Issue Description:
The ISO8601 DateFormatter which is apparently also used for the Codeable dateDecodingStrategy/dateEncodingStrategy iso8601 does not parse/validate all ISO8601 dates as expected.
It especially does not accept iso8601 dates with sub seconds.
Expected:
2017-09-03T10:08:00Z => valid iso8601 date
2017-09-03T10:08:00.000Z => valid iso8601 date
Actual:
2017-09-03T10:08:00Z => valid iso8601 date
2017-09-03T10:08:00.000Z => invalid iso8601 date
Minimal Sample Code:
let decoder = JSONDecoder()
decoder.dateDecodingStrategy = .iso8601
try decoder.decode([Date].self, from: "["2017-09-03T10:08:00Z"]".data(using: .utf8)!) // works
try decoder.decode([Date].self, from: "["2017-09-03T10:08:00.000Z"]".data(using: .utf8)!) // throws
Version Info:
Used Xcode 9 Beta 6 in iOS 11 Simulator on macOS Sierra 10.12.6.
Note:
I discovered this while consuming an REST API that is implemented in JavaScript (node.js). When creating a Date object in JavaScript and transforming it to an iso string using "toISOString" (e.g. "(new Date()).toISOString()") it creates a date string including sub-seconds (e.g. "2017-09-03T10:08:00.000Z").
This means that one cannot consume a "standard" JavaScript API with Swift's builtin Codable date parser and need to create a custom DateFormatter (e.g. with the pattern: "yyyy-MM-dd'T'HH:mm:ss'.'SSSZZZZZ").
This behavior is really inconvenient and a great bummer for Swift's Codeable support.
I'm not an expert on date formats but I expected this to work and it took me some time to dig through the differences why this did not work. Would be great if we could save this time waste from future developers.

extension JSONDecoder.DateDecodingStrategy {
    static let iso8601WithSeconds = custom {
        let container = try $0.singleValueContainer()
        let string = try container.decode(String.self)
        let formatter = ISO8601DateFormatter()
        formatter.formatOptions = [.withInternetDateTime, .withFractionalSeconds]
        guard let date = formatter.date(from: string) else {
            throw DecodingError.dataCorruptedError(in: container,
                  debugDescription: "Invalid date in iso8601withSeconds: " + string)
        }
        return date
    }
}

gives a .iso8601WithSeconds variant that solves this issue. (Swift 5.5)
Use like
let decoder = JSONDecoder()
decoder.dateDecodingStrategy = .iso8601WithSeconds


Add POST /v1/chains/<chain_id>/messages/<message_hash>/signatures

Closed by https://github.com/5afe/safe-client-gateway-nest/pull/282


Fix non-bundled tests against macOS system SQLite

On macOS we fail some tests when they're run against system SQLite. These may be bugs in the macOS system SQLite (since PRAGMA compile_options says that BUG_COMPATIBLE_20160819 is enabled, which seems a little ominous), but the fixes for these are easy enough.
I only bothered checking that the mode behaves as expected for bundled in test_pragma_query_row and not in pragma_update_and_check, since the latter seems to be mostly about testing that compilation doesn't fail.

I'm just going to land this after CI is green since it's trivial and is bothering me right now.


Force-complete no longer works in new agent (1.0.5)

Creating this issue now that I can collect facts. This workflow was moved to "force-complete" - via webpage - in testbed:
amaltaro_TaskChain_Multicore_Agent105_CDB16_HG1504_150409_002328_4571
and it
a) did not kill the pending jobs
b) is still creating new jobs
If I open GQ, I no longer see any elements in there. The same applies for the workqueue_inbox doc, it has been deleted.
Investigating WorkQueueManager in the agent, I see the following interesting logs:
2015-04-09 08:33:16,666:INFO:WorkQueue:Canceling work for workflow(s): set(['amaltaro_TaskChain_Multicore_Agent105_CDB16_HG1504_150409_002328_4571'])
2015-04-09 08:33:17,211:INFO:DashboardReporter:Handling 1 jobs
... more hundreds of lines reporting to dashboard ...
2015-04-09 08:35:35,624:ERROR:WorkQueue:Aborting amaltaro_TaskChain_Multicore_Agent105_CDB16_HG1504_150409_002328_4571 wmbs subscription failed: (DatabaseError) ORA-00060: deadlock detected while waiting for resource
 'UPDATE wmbs_job SET retry_count = :retry WHERE id = :job' {'job': 19458, 'retry': 99999}
2015-04-09 08:35:47,714:INFO:WorkQueueBackend:set replication from GQ to LQ
...
2015-04-09 08:45:49,643:INFO:WorkQueue:Waiting for parent queue to delete "amaltaro_TaskChain_Multicore_Agent105_CDB16_HG1504_150409_002328_4571"

It's not clear to me also why it tries to update retries for one specific job to 99999.

and for completeness, these blocks have been deleted from local workqueue and workqueue_inbox as well, though I can still list them in wmbs_workflow table. I guess there is no way to stop this wf :-)

Actually it does not happen only in the new agent, I found a similar wmbs error in the 1.0.0 as well.
And it's not easily reproducible.
What about the following fix: https://github.com/amaltaro/WMCore/commit/b52e0acc8db98293cd86f1090baf1e99a2cad9f7
@ticoann ?

Hi Alan, it seems there are 4 things happen when killWorkflow calls,
https://github.com/amaltaro/WMCore/blob/b52e0acc8db98293cd86f1090baf1e99a2cad9f7/src/python/WMCore/WorkQueue/WorkQueue.py

kill BossAir jobs.
update couchdb status of the jobs
update the dashboard status of jobs.
change the wmbs db job status.

I am guessing the problem is in 2. But not completely sure. Was that the a lot of jobs needed to be killed?
I think it is safe to clean the db as your patch did if the exception happens 2 or 3 but we still make 4 happen.
Maybe we should patch https://github.com/dmwm/WMCore/pull/5682 first which might reduce the couch failure case?

From the error message, I'd say it fails in 4), when updating wmbs database.
I agree, I'll first apply #5682 to testbed and run a few tests over the night and then we discuss further this issue ;)

Sorry, I didn't read the error message carefully. In that case, I don't know how to handle that. I think we should check whether it will cause any side effect when wmbs job status is not updated.

Fixed by #5800


Use the generic SLF4J logging facade.

Remove references to LOG4J
Optimze imports -> remove unused and do lexicographically ordering.

Integration tests succeeded: https://beta-jenkins.mcc.schubergphilis.com/job/cosmic/job/0002-tracking-repo-branch-build/166/

Ping @miguelaferreira @bheuvel @wilderrodrigues


Remoteink USB connection issues, advice needed

Hello Alexander and Nikolai,
I received a request to connect 2 devices together: Raspberry Pi 2 and Pocketbook Inkpad 3 as a screen via USB. Can't manage to get the USB connection via remoteink to work and ask you for any advice you could offer.
Wifi connection works without issues, but the person who made the request wants to avoid using wireless signals. Been trying to use a pl-25a1 USB2 chipset cable & USB2 (female) -> MicroUSB (male) for it. Inkpad 3 has been rooted and got USB networking turned on. When connected together via cable, Raspberry shows USB network IP and port, yet no interface pops up in remoteink, so I believe the issue could be on the Pocketbook side of things.
Do you know of compatibility between remoteink and Inkpad 3?
Do you know of any way to check if Inkpad 3 contains g_ether module?
Could the adapter be an issue in the USBNet connection?
Is the cable good for what I'm trying to do?

Hi @Devindar-hash!

Do you know of compatibility between remoteink and Inkpad 3?

I have not tried remoteink on InkPad 3 myself but I saw a thread with people trying that. Someone wrote that rooting may help, however there are no reports where people managed to make it work via USB.

Do you know of any way to check if Inkpad 3 contains g_ether module?

I don't know for sure but using a terminal to explore the internal file system may help.

Could the adapter be an issue in the USBNet connection? Is the cable good for what I'm trying to do?

I don't know for sure but I doubt the cable model makes a difference here (in case if you know that your cable is not corrupted).

Thank you for the reply @borzunov!
I will try looking through the system, otherwise a lack of records on the net of the USB connection between those 2 devices being possible is somewhat disheartening.
Have a great day!


Add renovate config

:tada: This PR is included in version 8.0.1-develop.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 8.0.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 8.1.0-develop.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


mattermost service: how to specify secrets?

The mattermost module has an option to make mattermost's config immutable (services.mattermost.mutableConfig = false), and specify the server's entire config via the module / extraConfig hook. Doing this, however, I cannot figure out a way of then specifying secrets (e.g. the password for mattermost's mail account) without putting them in the nix store, which is world-readable.
Have I missed something, or is there currently really no way to do that?

You will probably have to set mutableConfig to true and add secrets through the console. Other nixos modules have started copying config files to the service's data directory using envsubst, which will look for all variables referenced in a file and replace with the relevant environment variable. So you can set secrets using systemd's EnvironmentFiles which won't be in the nix store, and reference them within config files.
But mattermost doesn't do this. So the best current option with the current module is to set secrets imperatively. Optimally, the module would be changed to allow for setting declarative secrets.


remove non-mesosphere users from dcos repo owners

High-level description
What features does this change enable? What bugs does this change fix?
Remove users who are no longer at Mesosphere from owners.
Corresponding DC/OS tickets (obligatory)
These DC/OS JIRA ticket(s) must be updated (ideally closed) in the moment this PR lands:

DCOS_OSS- Foo the Bar so it stops Bazzing.

Related tickets (optional)
Other tickets related to this change:

DCOS_OSS- Foo the Bar so it stops Bazzing.

Checklist for all PRs

[ ] Added a comprehensible changelog entry to CHANGES.md or explain why this is not a user-facing change:
[ ] Included a test which will fail if code is reverted but test is not. If there is no test please explain here:
[ ] Read the DC/OS contributing guidelines
[ ] Followed relevant code rules Rules for Packages and Systemd

Checklist for component/package updates:
If you are changing components or packages in DC/OS (e.g. you are bumping the sha or ref of anything underneath packages), then in addition to the above please also include:

[ ] Change log from the last version integrated (this should be a link to commits for easy verification and review): example
[ ] Test Results: [link to CI job test results for component]
[ ] Code Coverage (if available): [link to code coverage report]

PLEASE FILL IN THE TEMPLATE ABOVE / DO NOT REMOVE ANY SECTIONS ABOVE THIS LINE
Instructions and review process
What is the review process and when will my changes land?
All PRs require 2 approvals using GitHub's pull request reviews.
Reviewers should be:

Developers who understand the code being modified.
Developers responsible for code that interacts with or depends on the code being modified.

It is best to proactively ask for 2 reviews by @mentioning the candidate reviewers in the PR comments area. The responsibility is on the developer submitting the PR to follow-up with reviewers and make sure a PR is reviewed in a timely manner. Once a PR has 2 ship-it's, no red reviews, and all tests are green it will be included in the next train.

@mesosphere-mergebot bump-ee

@mesosphere-mergebot label ready for review

@mesosphere-mergebot bump-ee

@mesosphere-mergebot bump-ee

@mesosphere-mergebot bump-ee

@sambatyon please close this PR / add the people we removed back. Removing people who no longer work at mesosphere from this file is apparently something that should be handled with care.

Current owners are like Mesosphere shepherds who can a) Override Failures, b) Apply Ship-it c) merge it too.
We could also consider renaming the file a mergebot-owners.json

Let's go ahead with this change. Having said that, if the members prefer to be owners, we should include them. This looks non-controversial to me and can be backed out if we need to.
We are going ahead with applying the ship-it and including it in 1.10 train.
Thank you!

@mesosphere-mergebot label ship-it


I2C

I suspect P3+P4 are I2C and used to communicate with the RP2040 seen on the prototype M.2 HAT. The BCM2712 has two pins muxed to the I2C peripheral and they're named PCIE_SCL/SDA. It isn't the RP1 either as that has a separate I2C bus.
These two pins are configured with the weak internal pulldown enabled and always read as low. The M.2 HAT presumably has the missing I2C pullup resistors.
114: a1    pd | lo // PCIE_SDA/GPIO14 = SPI_S_MOSI_OR_BSC_S_SDA
115: a1    pd | lo // PCIE_SCL/GPIO15 = SPI_S_SCK_OR_BSC_S_SCL

Should be easy enough to confirm by running pinctrl before & after pulling the pins high.

Thanks for this. I'll add provision for this on the board. That's really useful knowledge. I'm also pretty sure that P1 is RST and P2 is CLKREQ (based on probing around with the scope some more). Means there is likely no presence detect (or some magic the RP2040 is doing over I2C with the driver?).

I expect autodetection would be via I2C like the Poe HATs. The prototype M.2 HAT has a fan connector and current sensing so that'll be via I2C as well if it ends up in the release board. I don't know how much of this is implemented in the public firmware though.
Adding a couple pullup resistors might make it show some activity during startup.

Will give that a shot. I'm just looking at the kernel & DT overlay source on the Pi5 GitHub. See if I can work out a way to tell SCL vs SDA when there's no data/clock on the bus.

Pull up only 1 and see what changes in pinctrl?

Using pinctrl as suggested by @trejan the following can be observed:
$ diff idle.txt p3_high.txt
< 114: a1    pd | lo // PCIE_SDA/GPIO14 = SPI_S_MOSI_OR_BSC_S_SDA
> 114: a1    pd | hi // PCIE_SDA/GPIO14 = SPI_S_MOSI_OR_BSC_S_SDA

$ diff idle.txt p4_high.txt
< 28: no    pd | lo // PCIE_RP1_WAKE/GPIO28 = none
> 28: no    pd | hi // PCIE_RP1_WAKE/GPIO28 = none
< 115: a1    pd | lo // PCIE_SCL/GPIO15 = SPI_S_SCK_OR_BSC_S_SCL
> 115: a1    pd | hi // PCIE_SCL/GPIO15 = SPI_S_SCK_OR_BSC_S_SCL

Interesting that the PCIE_WAKE signal appears to be trigged with the clock being high. Taking this literally, a low BSC_S_SCL/GPIO15 indicates the PCIE_nWAKE request, too? Perhaps the signalling is to use the I2C clock stretching condition to signal a wake?
Couldn't get any life out of P1 and P2. Grounding P2 resulted in no difference from pinctrl. I was hoping it may have triggered RP1_PCIE_CLKREQ_N (as below) but nothing. Most likely this is for the RP1 chip as RP1 is in the name.

36: no    pd | lo // RP1_PCIE_CLKREQ_N/GPIO36 = none

Closing ticket. I2C pins identified. Thanks for the help @trejan!

Looking at the official Pi5 PCIe documentation,
P4=PCIE_SCL and WAKE is correct.
P3=PCIE_SDA also appears to serve as a PWR_EN signal.


How to use Prisma

We should document how to use Prisma with NuxtHub in the recipes now they support D1:
https://developers.cloudflare.com/d1/tutorials/d1-and-prisma-orm

(there might be integration issues with wasm. it is addressed in unwasm but not sure until testing with db0 so just you know)

Hello everyone, I would like to inquire about the progress of this matter. Is it feasible to implement it in the NuxtHub project?
However, I could not find any usage instructions in the documentation.

I did not take the time to look at it, but if you want to help finish https://github.com/nuxt-hub/core/pull/58 this would be awesome 💚  (Sylvain does not have the time anymore to work on it)


Remove old-spark leftovers

After moving all spark based connectors on backend module, this removes some old code plus unifies any duplications

@alissapajer this PR cleans up some left overs after introducing backend module to spark. Also some renaming applied for readability. Would be also cool to have it in master ASAP (before dynamic loading) so if review possible today that would be awesome

@djspiewak FYI this will cause minor conflicts in #2756 when it lands.


Add get harbor version case

Add get harbor version case

Coverage remained the same at 64.549% when pulling 71ed6284d24fa428f90a6129c3ac30de7b778601 on sigsbee:version into 4eec58642599b07423dafa6bfa4207cbd318a45e on vmware:master.

Merci

Thanks


CLI exit code is always 0, even if there are errors

It's difficult to tell when Dependency-Check fails to run. For example, if it can't update the database due to internet issues, or if the analysis crashes for one reason or another.
I've got a solution in place that reads the log file and looks for SEVERE messages, but it seems dirty. Could the CLI return a non-zero exit code when a fatal error happens? It would be extra helpful to have a few different codes to signify different meanings.

Yes, I can make this happen. However, since this change will need to alter more then just the CLI plugin I won't be able to implement in the upcoming release (which will be within a week). I'll put this on the road map for 1.2.11 depending on what other changes get bundled.
Thanks for the suggestion!
--Jeremy

Quick note for myself as I implement this - be sure to include the following as non-zero exit codes:

unable to download NVD
incorrectly configured suppression file
scanning non-existent directory
check the code base for any error logging (as opposed to warn/info/debug) - the errors may need to be added to the non-zero exit code list.

This has been resolved in 1.4.2

Thanks for doing this!


Hello World tutorial for Orleans should be updated for Orleans 7

Issue description
Hello World Tutorial for Microsoft Orleans is using an older Orleans version so it doens't work in Orleans 7:
https://learn.microsoft.com/en-us/dotnet/orleans/tutorials-and-samples/overview-helloworld
The README.md in the GitHub samples directory, however, seems to have the right information for Orleans 7:
https://github.com/dotnet/samples/tree/main/orleans/HelloWorld
Target framework

.NET 7

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

ID: babf6e7d-18bc-3170-3e35-ec75a0373c55
Version Independent ID: b21f264d-2795-d68f-4c97-8af273562de5
Content: Tutorial: Hello world
Content Source: docs/orleans/tutorials-and-samples/overview-helloworld.md
Product: dotnet-orleans
GitHub Login: @IEvangelist
Microsoft Alias: dapine

This was actually already addressed...


feat(rust): make JSON serialization of DataType and Field public

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 77.92%. Comparing base (6101528) to head (b95766f).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3161      +/-   ##
==========================================
- Coverage   77.96%   77.92%   -0.05%
==========================================
  Files         242      242
  Lines       82455    82455
  Branches    82455    82455
==========================================
- Hits        64290    64252      -38
- Misses      14978    14979       +1
- Partials     3187     3224      +37

Flag
Coverage Δ

unittests
77.92% <ø> (-0.05%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

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

🚨 Try these New Features:

Flaky Tests Detection - Detect and resolve failed and flaky tests

very nice!


Hotfix-load-311-error (prod)

I just deployed, but, feel free to merge and redeploy if this is ready.


Old listen stop working after some time

I still have old listen system (because Slovakian users got updates as last), and now after while of working the listen dont returning anything and writing timeout.
Log:
//250 pulls before
info Got answer in  560
info Got answer in  2705
info Got answer in  654
info Got answer in  7196
info Got answer in  443
info Got answer in  5292
info Got answer in  464
info Got answer in  4149
info Got answer in  401
info Got answer in  8117
info Got answer in  422
info Got answer in  10277
info Got answer in  407
info Got answer in  50463
info Got answer in  50363
info Got answer in  49075
info Got answer in  5400
info Suppressed timeout error.
info Got answer in  103009
info Got answer in  54642
info Got answer in  12405
info Got answer in  19886
info Suppressed timeout error.
info Suppressed timeout error.
info Got answer in  158397
info Suppressed timeout error.
info Got answer in  77284
info Suppressed timeout error.
info Got answer in  63720
info Got answer in  21428
info Got answer in  9320
info Got answer in  22153
info Got answer in  25389
info Got answer in  23446
info Suppressed timeout error.
info Suppressed timeout error.
info Got answer in  153654
info Got answer in  654
info Got answer in  1747
info Got answer in  341
info Got answer in  490
info Got answer in  629
info Got answer in  2200
info Got answer in  336
info Got answer in  348
info Got answer in  429
info Got answer in  467
info Got answer in  493
info Got answer in  340

Not sure what we can do about this...

After shutdown and trying to relogging its going only to logged in action, and after next relog error in first Pull Request. I logged in browser, but account is not blocked. So I relogged via bot, saved appState, and now its works nice. So maybe expire of cookie or something.. ?


Publish 8.2-20230527001736+0000

Publish 8.2-20230527001736+0000

@bot-gradle test and merge

I've triggered a build for you.

Pre-tested commit build failed.

I've triggered a build for you.

Your PR is queued. See the queue page for details.

Error while scheduling pre-tested commit, please contact the administrator.


Create API endpoints

Create the API endpoints our smart machine will use (with blank operations).

Issue closed by PR #31


fix: address akmods latest bug

Akmods do not support the latest tag. This just sets it to 39 if they have latest in their system

The issue with this is that it's not dynamic, you would need to change this every time new Fedora release comes in.

The issue with this is that it's not dynamic, you would need to change this every time new Fedora release comes in.

it is not meant to be dynamic. I think its ok to have hardcoded values. We can just come back and revisit this on the next release. Releases happen on a ~6month cadence.

it is not meant to be dynamic. I think its ok to have hardcoded values. We
can just come back and revisit this on the next release. Releases happen on
a ~6month cadence.
On Wed, Feb 28, 2024 at 8:02 AM fiftydinar @.***> wrote:

The issue with this is that it's not dynamic, you would need to change
this every time new Fedora release comes in.
—
Reply to this email directly, view it on GitHub
https://github.com/blue-build/cli/pull/105#issuecomment-1969049546, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ACGZFXTH6VZE6Z7PEDCKDEDYV42GFAVCNFSM6AAAAABD6BV5FSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRZGA2DSNJUGY
.
You are receiving this because you authored the thread.Message ID:
@.***>

We get the OS version from labels. Is there a reason why that's not working for you? I'm with @fiftydinar on this, we shouldn't hard code this in and instead find a more reliable way to get the information we need

@bayou-brogrammer it would be maybe a good idea to land last "default to main" fix in a separate PR.

@bayou-brogrammer it would be maybe a good idea to land last "default to main" fix in a separate PR.

crap didnt realize i was still on this branch


Fix and centralize the Node.js app tutorial

There are currently two different versions of the same JS tutorial example in this repository, and both are broken. This PR fixes the broken bindings from #296 in the dev/node_app example and changes examples/js to point to this new example, to reduce confusion and allow for this resource to be more easily maintained in the future. This PR also makes some modifications to the Docker setup in dev to ensure networking works correctly in the current version of Docker.
In sum:

remove duplicate example in examples/js and point to the dev development setup
fix broken bindings in the Node.js example
improve dev Docker setup

Codecov Report

Merging #350 (ea0947c) into master (0856d8f) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #350   +/-   ##
=======================================
  Coverage   27.27%   27.27%
=======================================
  Files          88       88
  Lines        5122     5122
=======================================
  Hits         1397     1397
  Misses       3575     3575
  Partials      150      150

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 0856d8f...ea0947c. Read the comment docs.

Hey @levb and @mickmister, can I get your review and merge on this JS tutorial fix? Please let me know if you have any questions and feel free to directly edit my updates. 🚀

I'm doing a more thorough review, though I wanted to point :point_up: out

@mickmister Thanks for the initial review. Do you have the bandwidth to help us get this merged before Wednesday? We were hoping to have these fixes implemented for the 7.0 release because we're going to promote these resources to encourage adoption of the App framework.

I'm going to do another pass on these tutorials just to make them tighter, set up the Docker network ideas we're discussing, and move most of the code examples into the repo and out of the tutorial to remove redundancy for future maintenance. Since that's the case, we can also tackle that dropping mattermost-redux at that time and make sure we have the best process laid out for the developer.

@azigler I see you're developing off the master branch of your fork. I recommend using a different branch, as this could otherwise cause issues with sync'ing between the forks.

Since that's the case, we can also tackle dropping mattermost-redux at that time and make sure we have the best process laid out for the developer.

Makes sense to me :+1: As a side note, the @mattermost/types package actually needs an update for new types from App Framework 1.0

@azigler I see you're developing off the master branch of your fork. I recommend using a different branch, as this could otherwise cause issues with sync'ing between the forks.

Since that's the case, we can also tackle dropping mattermost-redux at that time and make sure we have the best process laid out for the developer.

Makes sense to me 👍 As a side note, the @mattermost/types package actually needs an update for new types from App Framework 1.0

Is there a different branch you recommend I use? Or should I make a new branch in the future for these updates?

Thanks @mickmister for the review! @levb, let me know if you have any questions ahead of merging this. Would love to get this merged soon to coincide with the 7.0 launch, but I'm open to any feedback or concerns you might have. Thanks!
cc @BenLloydPearson

@levb @mickmister Hi y'all! Just wanted to follow up to see if we could get a merge on this one? Let me know if either of you have any questions.
cc @BenLloydPearson

@levb @mickmister Okay, I understand the confusion now. In a version of this I was working on, the channel_header and command bindings didn't both work if they used the same form. I thought this was by design but it's likely my local example just wasn't working. Based on y'alls feedback, I (think I) understand now how this should be structured. I did some testing to make sure this works. Everything is more clear to me now. I committed some changes to reflect the new bindings, which removes the redundant form. I also opened a new PR on mattermost-developer-documentation and made relevant updates there.
When this PR is closed, I will move off master to my own branch as Michael suggested. Based on the other things we discussed here, a future PR will address:

using a Docker network with an external repo instead of encouraging development in dev/
moving off mattermost-redux

Please let me know if there are still outstanding issues to address here, and thank you for your patience!

Closing this PR because /examples and /dev are moving to https://github.com/mattermost/mattermost-app-examples.


Burndown filtering

Burndown charts aren't able to be filtered by a custom boolean field.

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

ID: a9d627b9-9aa8-c52c-3178-cffbefe9727a
Version Independent ID: 31967bb3-2635-da97-782c-641f432750f7
Content: Configure Burndown & Burnup widgets - Azure DevOps
Content Source: docs/report/dashboards/configure-burndown-burnup-widgets.md
Product: devops
Technology: devops-analytics
GitHub Login: @KathrynEE
Microsoft Alias: kaelli

@sandyteenan - I will update the article to indicate this feature limitation. If you'd like to file a feature request, please go to our Developer Community page.


fetchMock.get(string, "") fails due to "fetch-mock: Invalid parameters passed to fetch-mock"

fetchMock.get fails due to fetch-mock: Invalid parameters passed to fetch-mock if the url parameter is a string and the response argument is "". Non-empty strings work as expected. Example:
import fetchMock from "fetch-mock";

afterEach(() => {
  fetchMock.reset();
});

describe('fetchMock', () => {

  it('allows returning empty response', () => {
    fetchMock.get("http://bla.blu", "");
  })
})

I suspect this to be a bug because the response parameter can be a string and an empty response is valid for HTTP requests. Furthermore non-empty string are returned as response as expected.
The only related issue I found is #184 which is about improving the error message. It's fine afaik, I wouldn't mind more information which types are expected, though, but that's a separate concern, and since types are provided, it's not necessary.
A complete example project is provided at https://gitlab.com/krichter-sscce/fetch-mock-empty-string-invalid-parameter. The behaviour can be triggered by running yarn test in the source root.
Version information from yarn.lock:
<EMAIL_ADDRESS>  version "7.7.3"
  resolved "https://registry.yarnpkg.com/fetch-mock/-/fetch-mock-7.7.3.tgz#6a3f94cfed6e423ab7f5464912982030da605335"
  integrity sha512-I4OkK90JFQnjH8/n3HDtWxH/I6D1wrxoAM2ri+nb444jpuH3RTcgvXx2el+G20KO873W727/66T7QhOvFxNHPg==
  dependencies:
    babel-polyfill "^6.26.0"
    core-js "^2.6.9"
    glob-to-regexp "^0.4.0"
    lodash.isequal "^4.5.0"
    path-to-regexp "^2.2.1"
    whatwg-url "^6.5.0"

Yes that's a bug alright.
I'll get it fixed soon.

released as 9.2.2


Access SQS queue using "AmazonSQSClient" without using AcccessKey and SecretKey

How we can access SQS queue using "AmazonSQSClient" without using AcccessKey and SecretKey? Is there any options or code sample which use Role instead of AccessKey and SecretKey. We are trying to access SQS queue in our AWS environment where Lambda has Role assigned who has access to SQS and we are not allowed to use AccessKey and SecretKey.
Any options in current AWS SDK?

SDK should pickup the credentials set in the environment variable by Lambda automatically.  Is this not working for you?

Closing due to inactivity.


Patch 15

Updated to remove link to updating a cluster as it was in this document. Added headings for existing cluster and new cluster (enabling workload identity)
Changed get pods output to match other documents. Output rather than a table.
Added extra output from last kubectl get command.

@greg-lindsay
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@JackStromberg please review

Thank you for the feedback!  We will be making additional changes to this document later this month.  I'll make sure the example output is included as part of those changes.
Cheers!
Jack
#please-close


Strange color with Nintendo Logo in Zelda: Ocarina of Time

OS: Slackware64-current
mupen64plus-2016.10.09_507893d-x86_64-1_git
When using rsp-cxd4 with mupen64plus and the game Zelda: Ocarina of Time the Nintendo logo will have a strange color. This does not occur with rsp-hle and the video plugin does not make a difference. Is there a reason it looks like this?
Apitrace - http://ks392457.kimsufi.com/orbea/stuff/trace/mupen64plus/cxd4_nintendo_logo.trace.xz
rsp-cxd4

rsp-hle

rsp-z64 does it too. I suspect this is either an issue directly with rsp-cxd4 or perhaps an issue with the mupen64plus-core which LLE rsps expose?

I find no such issue on my 64-bit port of Mupen64, but I cannot comment on Mupen64 "Plus" given that I don't keep track of what goes on in their fork.
Raw CPU frame buffer:
![http://i.imgur.com/kRFnlLT.png]
Post-processed for DAC:
![http://i.imgur.com/c6KXpHt.jpg]
Does Mupen64Plus let you test an interpreter CPU core instead of dynamic re-compilers?  Maybe you should check if this graphical issue happens with the stable core.  If so, then I propose a regression in their fork of this RSP emulator.
I haven't yet upgraded to Slackware 14.2 or current from 14.1, although I doubt that's related.

This does not occur with rsp-hle and the video plugin does not make a difference.

HLE RSP basically just means that the RSP is emulated by the video plugin, not the RSP plugin, so the fix can't come from within rsp-hle.  The fact that you don't see this issue when using the video plugin (any HLE video plugin, regardless of what you choose) to emulate the RSP instead of the RSP plugin emulating the RSP suggests further that this may be exposing an issue in the modified Mupen64 core as you suggested.

To be honest I have noticed for a while with angrylion in mupen64plus-libretro, but it was not till GLupeN64 added the cxd4 rsp that I realized it was connected to it. After this I confirmed it happens with upstream mupen64plus too for the gfx plugins that are able of using the cxd4 rsp.
Furthermore looking at your images and then the following youtube video it seems the using the HLE rsp does not get it quite right either and it should rather be something in the middle for both of my images.
https://youtube.com/watch?v=deBvHxA38hM
I also did not realize mupen64 was still usable, I will have to look into setting that up to see if I can reproduce it there or not. I suspect this is entirely in the mupen64plus core and / or their cxd4 rsp.  Thanks for the reply!

I don't memorize by heart all that I have done to get Mupen64 64-bit working, but it does work out of the box right away with a make on my Slack at least:
http://www.emutalk.net/threads/56150-Mupen64-for-x86-64-plugin-developers
It's what I used for the images I uploaded showing my result.  I have historically had the same result also on Windows with Project64 and Hacktarux's untouched 32-bit Mupen64 0.5.
It is a shame that Mupen64Plus broke the plugin system's conformance to other emulators.  If they hadn't, you could take your build of my RSP plugin from Mupen64Plus to some other emulator still using the zilmar-spec plugin model and run it across there.  Seeing the issue gone then would basically prove the CPU core at fault.
I can only think to suggest at the moment winding back to older, legacy versions of Mupen64Plus, possibly back to when they still used the zilmar-spec plugin model (pre-1.5 versions), to see if the older versions of their core (or their fork of my RSP plugin from those years ago) might show when this issue began.

Furthermore looking at your images and then the following youtube video it seems the using the HLE rsp does not get it quite right either and it should rather be something in the middle for both of my images.

I was aware that the result in your screen captures was off as well, but that isn't caused by the HLE RSP module in Mupen64Plus, which simply asks the graphics plugin to do the RSP emulation for it.  You can probably find better results than what you posted by changing the graphics plugin to one that does HLE more accurately for that game or--in the absence of this issue with my RSP plugin (or ziggy's)--a LLE graphics plugin like angrylion's.
So the rsp-hle module is mostly a dummy plugin that gets the video and audio libs to do all the RSP.

Fixed?


removing ExecutorBase::start

The ExecutorBase::start was used to be able to queue up method calls and start executing them later. The reason why we needed it was because stream automatons were implemented without SubscriberBase/SubscriptionBase and the methods were synchronous. We needed to set several pointers first before we allowed processing the stream frames.
Now all stream automatons are implemented with SubscriberBase/SubscriptionBase and so their methods are queued on executor automatically. We don't need to delay processing of the method calls anymore.

looks like a dodgy CI build with timeout, kick off again?


[BUG] Numbers get printed differently

from rich.console import Console

console = Console()

console.print(f"[Task 30] ==> On Webpage", style = f"bold bright_yellow")

Using the following code, the number 30 gets printed in a cyan/blue color rather than a bold bright yellow

Please see docs on highlighting


Detect redistributable errors

failed during eqgzi with signal #-1073741515
https://aka.ms/vs/17/release/vc_redist.x64.exe
needs to be downloaded

if you go to regedit, and put in the top bar this path: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\VC\Runtimes\X64
should exist, I think..


Validation set

Excellent work!
I have some questions about the code. The validation set is not used, right?
https://github.com/xyjigsaw/CENET/blob/68a564afe1011b523d8c888fff9c165816f8e578/main.py#L213

Thank you for your attention. Sorry for that there are a few differences between the cleaned published codes and our original codes. The final seleted models are based on the results on the validation set.


Document can't search for how to integrate the upload images to the site

Document can't search for how to integrate the upload images to the site
Any links to the document location?

This project isn't maintained anymore. If you'd like to add a fix a PR is welcome otherwise you might want to fork it or look for another editor.


process.env["PORT"] builds as process.env["3001"]

Describe the bug
process.env["PORT"] builds as process.env["3001"]
overriding the port here as seen below does not do anything:
{
kit: {
		adapter: adapter({
			out: 'build',
			env: {
				host: 'configuregator.dev',
				port: '3001',
			}
		}),
		target: '#svelte'
}
}

I then tried setting a node ENV variable when running my built sveltkit project
PORT=3001 node index.js
The result is a built output with the lines
const port = process.env["3001"] || (!path && '3000');

which is undefined and the value is the name of the property
Reproduction
See the steps above
Logs
N/A

System Info
npx: installed 1 in 1.366s

  System:
    OS: macOS 11.5.2
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
    Memory: 2.49 GB / 32.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 14.17.6 - /usr/local/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 6.14.15 - /usr/local/bin/npm
  Browsers:
    Chrome: 97.0.4692.71
    Firefox: 95.0.2
    Safari: 15.0

Severity
blocking all usage of SvelteKit
Additional Information
I cannot specify ports which blocks deployment

See #2300.

Okay that's an unexpected way of doing things, tripped me up for sure. Nonetheless, how then do you change the port and host name?

See https://github.com/sveltejs/kit/tree/master/packages/adapter-node#env


drivers: add in-memory driver

Create an in-memory driver from FakeAccessor.
Change settings to be able to support multiple drivers.
Update documentation.

This change is

Sorry for the somewhat long PR. It was written offline and is pretty hard to split.

Review status: 0 of 14 files reviewed at latest revision, 5 unresolved discussions.

CONFIGURATION.md, line 10 [r1] (raw file):

produciton
typo

CONFIGURATION.md, line 25 [r1] (raw file):

debubging
typo

biggraphite/utils.py, line 55 [r1] (raw file):

    except (TypeError, KeyError):
        try:
            res = getattr(settings, name)

you may avoid the second try/except by putting a default value in getattr, eg (settings, name, default)
I also would have directly put the getattr in the first place but I am maybe missing a case here.

biggraphite/utils.py, line 60 [r1] (raw file):

    # Fallback to env.
    if res is None and name in os.environ:
        res = os.environ[name]

I would have put a getattr here instead of the name ins os.environ test

biggraphite/drivers/memory.py, line 94 [r1] (raw file):

        dots_count = glob.count(".")
        glob_re = re.compile(fnmatch.translate(glob))
        for name in names:

we may use list comprehensions here

Comments from Reviewable

Review status: 0 of 14 files reviewed at latest revision, 5 unresolved discussions.

CONFIGURATION.md, line 10 [r1] (raw file):
Previously, wdauchy (William Dauchy) wrote…
> > produciton
> typo

Done.

CONFIGURATION.md, line 25 [r1] (raw file):
Previously, wdauchy (William Dauchy) wrote…
> > debubging
> typo

Done.

biggraphite/utils.py, line 55 [r1] (raw file):
Previously, wdauchy (William Dauchy) wrote…
> you may avoid the second try/except by putting a default value in getattr, eg (settings, name, default)
> I also would have directly put the getattr in the first place but I am maybe missing a case here.

it would not have the same behavior. We try to use it as a dict first, then as an object. And I can't use .get(key, default) because I'm not sure all indexable objects have this method.

biggraphite/utils.py, line 60 [r1] (raw file):
Previously, wdauchy (William Dauchy) wrote…
> I would have put a getattr here instead of the name ins os.environ test

Done.

biggraphite/drivers/memory.py, line 94 [r1] (raw file):
Previously, wdauchy (William Dauchy) wrote…
> we may use list comprehensions here

Done.

Comments from Reviewable

Reviewed 14 of 14 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

:strong_lgtm:

Review status: 11 of 14 files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Release instructions

Add step by step instructions for a perfect release every time.

Should we put somewhere clearly what the password is @mattpalermo?

I am not sure. It will only be useful for those debugging the program. So if there is ever a documentation section for that, it might go in there? If I could add protection without a password I would but I don't think that's possible.


Performance/RegexpMatch auto-corrects match to match? when MatchData is used

Performance/RegexpMatch attempts to auto-correct 'match' to 'match?' when MatchData is not used. Unfortunately, it does not identify all uses of MatchData resulting in errant auto-corrects.
Expected behavior
RuboCop should identify Regexp.last_match() as a use of MatchData and not auto-correct.
Actual behavior
[Corrected] Performance/RegexpMatch: Use match? instead of match when MatchData is not used.
tt = ::Regexp.last_match(1) if /pa(tt)ern/.match(astring)
Steps to reproduce the problem
The cop appears to correct any use of '.match' in a conditional. Both of the following are corrected:
Regexp.last_match(1) if /pa(tt)ern/.match(astring)
if /pa(tt)ern/.match(astring)
Regexp.last_match(1)
end
RuboCop version
0.52.1 (using Parser <IP_ADDRESS>, running on ruby 2.4.3 x86_64-linux)

Thanks for opening issue.
This issue related to #5038 and fixed by #5569. These cases didn't reproduce at the edge RuboCop. Thank you.


How to avoid downtime when a service is updated?

I'm running Ambassador with 3 replicas but every time a service is updated, Envoy is restarted at the same time on all replicas and leads to downtime. On a simple load test with 100 req/sec I'm seeing close to 200 EOF errors which makes Ambassador not suitable for production use when services weight settings change several times per day. What's the recommended approach to deal with hot restarts?

Hmmmm, this is surprising. Can you give us a bit more detail about how you're setting up your test?
Thanks!

Hi @kflynn
I've pushed my configs to stefanprodan/k8s-podinfo under the deploy dir.
I've run these testes on GKE with a 4 nodes cluster n1-standard-2.
I've used a NodePort to eliminate the GCP LB.
From the my repo root run:
kubectl apply -f ./deploy/ambassador

This will create two ambassador pods with anti affinity, so you need at least 2 nodes to run it.
The  ambassador service is:
kubectl get svc -l component=ambassador
NAME         TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)                                     AGE
ambassador   NodePort   <IP_ADDRESS>   <none>        80:30080/TCP,443:30443/TCP,8877:30877/TCP   47m

Apply the blue app with:
kubectl apply -f ./deploy/ambassador-backends/blue-svc.yaml
kubectl apply -f ./deploy/ambassador-backends/blue-dep.yaml

This service will be mapped to blue.test host. Test it with:
curl -H "Host: blue.test"  http://<K8S_IP>:30080/version
commit: 7b72c79
version: 0.0.8

Apply the green deployment:
kubectl apply -f ./deploy/ambassador-backends/green-dep.yaml

Now let's start the load test:
go get -u github.com/rakyll/hey
hey -n 10000 -q 50 -c 50 -m POST -d "testing" http://<K8S_IP>:30080/echo

After the load test has started, apply the green service:
kubectl apply -f ./deploy/ambassador-backends/green-svc.yaml

When the load test finishes you will see the failed requests:
Error distribution:
  [50]	Post http://<K8S_IP>:30080/echo: EOF

I've looked in the logs and right after the green service deployment, on both ambassador pods envoy restarts:
kubectl logs ambassador-7d878566ff-rc8mk ambassador --tail=3
[2018-02-23 21:58:17.338][174][warning][main] source/server/server.cc:318] caught SIGTERM
[2018-02-23 21:58:17.338][174][info][main] source/server/server.cc:363] main dispatch loop exited
[2018-02-23 21:58:17.338][174][info][main] source/server/server.cc:384] exiting

kubectl logs ambassador-7d878566ff-qj8bp ambassador --tail=3
[2018-02-23 21:58:20.523][175][warning][main] source/server/server.cc:318] caught SIGTERM
[2018-02-23 21:58:20.523][175][info][main] source/server/server.cc:363] main dispatch loop exited
[2018-02-23 21:58:20.524][175][info][main] source/server/server.cc:384] exiting

I hope this will help reproduce my use case.

Thanks for the detailed reproduction instructions. This isn't the expected behavior, so we'll be investigating this week.

Started looking at this @stefanprodan, but I noticed your Ambassador configs now reference host: podinfo.test rather than blue.test and green.test... any reason for the drift in documented reproducer and what's in the repo?

I manually edited the manifests and set blue.test and 'green.test` as described in the reproducers and then ran and was able to reproduce.
plombardi@plombowski ~/w/a/2/k8s-podinfo> hey -n 100000 -q 50 -c 50 -m POST -d "test" -host blue.test http://<IP_ADDRESS>:30080/echo
Summary:
  Total:	82.2572 secs
  Slowest:	0.3319 secs
  Fastest:	0.0147 secs
  Average:	0.0402 secs
  Requests/sec:	1215.6990
  Total data:	399808 bytes
  Size/request:	4 bytes

Response time histogram:
  0.015 [1]	|
  0.046 [68290]	|∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  0.078 [7630]	|∎∎∎∎
  0.110 [23850]	|∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  0.142 [157]	|
  0.173 [0]	|
  0.205 [12]	|
  0.237 [2]	|
  0.268 [5]	|
  0.300 [1]	|
  0.332 [4]	|

Latency distribution:
  10% in 0.0161 secs
  25% in 0.0175 secs
  50% in 0.0198 secs
  75% in 0.0775 secs
  90% in 0.0875 secs
  95% in 0.0957 secs
  99% in 0.1016 secs

Details (average, fastest, slowest):
  DNS+dialup:	 0.0000 secs, 0.0000 secs, 0.0184 secs
  DNS-lookup:	 0.0000 secs, 0.0000 secs, 0.0000 secs
  req write:	 0.0000 secs, 0.0000 secs, 0.0139 secs
  resp wait:	 0.0399 secs, 0.0147 secs, 0.3318 secs
  resp read:	 0.0001 secs, 0.0000 secs, 0.0147 secs

Status code distribution:
  [202]	99952 responses

Error distribution:
  [47]	Post http://<IP_ADDRESS>:30080/echo: EOF
  [1]	Post http://<IP_ADDRESS>:30080/echo: http: server closed idle connection

Access log capture from when green-svc.yaml is applied:
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.094Z] "POST /echo HTTP/1.1" 202 - 4 4 6 6 "-" "hey/0.0.1" "d79a970c-59ee-4b98-bffd-085967931d08" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.093Z] "POST /echo HTTP/1.1" 202 - 4 4 7 6 "-" "hey/0.0.1" "765c4d41-dff1-48d9-b45f-5de5cdaee109" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.089Z] "POST /echo HTTP/1.1" 202 - 4 4 13 12 "-" "hey/0.0.1" "bce5978b-adf4-4804-8140-e74587ed16b2" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.040Z] "POST /echo HTTP/1.1" 202 - 4 4 61 61 "-" "hey/0.0.1" "295b05c1-0fa6-497c-b1a8-3d4b28d94c73" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.039Z] "POST /echo HTTP/1.1" 202 - 4 4 62 62 "-" "hey/0.0.1" "b6dc84cb-470c-4a42-a6f2-88ed37d04365" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.038Z] "POST /echo HTTP/1.1" 202 - 4 4 64 63 "-" "hey/0.0.1" "9125bc58-6e69-4d83-9720-618869f5a42c" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.033Z] "POST /echo HTTP/1.1" 202 - 4 4 69 68 "-" "hey/0.0.1" "40189d66-cd37-49d1-863b-12f9a24fb4b2" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.111Z] "POST /echo HTTP/1.1" 202 - 4 4 0 0 "-" "hey/0.0.1" "f7af93b9-59e9-47db-b5ba-3137564d8a47" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.113Z] "POST /echo HTTP/1.1" 202 - 4 4 0 0 "-" "hey/0.0.1" "e8244e7c-7a27-40cf-9cac-e034ec5e4016" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.113Z] "POST /echo HTTP/1.1" 202 - 4 4 1 1 "-" "hey/0.0.1" "37aebf4c-070f-43ff-bd3a-4947db3d0630" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.115Z] "POST /echo HTTP/1.1" 202 - 4 4 1 0 "-" "hey/0.0.1" "2257934e-efbe-4749-80c6-bd7253c6ac08" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.114Z] "POST /echo HTTP/1.1" 202 - 4 4 2 1 "-" "hey/0.0.1" "e489a960-abb1-4691-a221-eb85846c468c" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.116Z] "POST /echo HTTP/1.1" 202 - 4 4 1 0 "-" "hey/0.0.1" "98ed5a71-1c77-40ad-a1e8-dce7788c7da0" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.115Z] "POST /echo HTTP/1.1" 202 - 4 4 2 1 "-" "hey/0.0.1" "1844b697-bd59-4f33-82b3-20a9fc28231a" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.077Z] "POST /echo HTTP/1.1" 0 - 4 0 45 - "-" "hey/0.0.1" "1ec8e984-16e3-470d-bac2-aace78fe2506" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.117Z] "POST /echo HTTP/1.1" 0 - 4 0 5 - "-" "hey/0.0.1" "41b937df-3e17-4e15-aa1d-8838ccbf6614" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.087Z] "POST /echo HTTP/1.1" 0 - 4 0 34 - "-" "hey/0.0.1" "1ca8cd6d-ace7-42cc-b661-1281f02c8e33" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.116Z] "POST /echo HTTP/1.1" 0 - 4 0 6 - "-" "hey/0.0.1" "bf726c14-b1b0-42e6-90d2-f6cb30f27c5b" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.082Z] "POST /echo HTTP/1.1" 0 - 4 0 40 - "-" "hey/0.0.1" "db6502f4-c8b0-4487-bb9c-d3d9cf9d0b2c" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.082Z] "POST /echo HTTP/1.1" 0 - 4 0 40 - "-" "hey/0.0.1" "d54894d7-f136-4af0-81fc-1fad0a0246fb" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.077Z] "POST /echo HTTP/1.1" 0 - 4 0 45 - "-" "hey/0.0.1" "63e84da9-e3b5-4441-b515-ad9c39112bab" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.087Z] "POST /echo HTTP/1.1" 0 - 4 0 35 - "-" "hey/0.0.1" "8f464f72-ee55-46f3-93a3-7a861cf3bcd1" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.116Z] "POST /echo HTTP/1.1" 0 - 4 0 7 - "-" "hey/0.0.1" "5780e9c6-eeb0-4da7-8b4b-00fa467371c3" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.083Z] "POST /echo HTTP/1.1" 0 - 4 0 40 - "-" "hey/0.0.1" "73a187c9-d201-4f57-84c9-39e87ffffa32" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.118Z] "POST /echo HTTP/1.1" 0 - 4 0 6 - "-" "hey/0.0.1" "e288203c-9f25-41e1-b0d8-15a0496e530d" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.079Z] "POST /echo HTTP/1.1" 0 - 4 0 44 - "-" "hey/0.0.1" "420e1b7d-a998-4780-801e-8541ea77bc9c" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.083Z] "POST /echo HTTP/1.1" 0 - 4 0 41 - "-" "hey/0.0.1" "d244ee6e-ca5c-4aed-b897-0e604b7663e5" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.083Z] "POST /echo HTTP/1.1" 0 - 4 0 40 - "-" "hey/0.0.1" "d2ca2ea2-f958-45e9-a738-a06f81fed3bd" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:08.080Z] "POST /echo HTTP/1.1" 0 - 4 0 43 - "-" "hey/0.0.1" "5e84d252-1077-4713-b075-a606d599a40b" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:07.326Z] "POST /echo HTTP/1.1" 202 - 4 4 5 4 "-" "hey/0.0.1" "db99d9b1-a8de-4653-b860-7968440dff4e" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:07.325Z] "POST /echo HTTP/1.1" 202 - 4 4 6 6 "-" "hey/0.0.1" "d85dbbc3-87e4-42d9-9322-2d624d1c9bc7" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:07.317Z] "POST /echo HTTP/1.1" 202 - 4 4 14 9 "-" "hey/0.0.1" "f57f513e-e625-46e6-9c3a-071b32b19bce" "blue.test" "<IP_ADDRESS>:9898"
ambassador-dccf76bdf-klx7j ambassador ACCESS [2018-03-05T16:31:07.323Z] "POST /echo HTTP/1.1" 202 - 4 4 10 9 "-" "hey/0.0.1" "143a9f17-431a-4046-ab02-01e1be72dbc8" "blue.test" "<IP_ADDRESS>:9898"

Turned off the weight stuff in green-svc.yaml and same failure behavior occurs.

I wanted to make sure this was actually an Ambassador issue and not something wonky with Services and underlying OS net infrastructure changes as a service is created so I took Ambassador out of the picture and just started a pod and ran hey from that pod...
/ # ~/go/bin/hey -n 100000 -q 50 -c 50 -m POST -d "test" -host blue.test http://blue:9898/echo
Summary:
  Total:	62.4067 secs
  Slowest:	0.3005 secs
  Fastest:	0.0002 secs
  Average:	0.0225 secs
  Requests/sec:	1602.3932
  Total data:	400000 bytes
  Size/request:	4 bytes

Response time histogram:
  0.000 [1]	|
  0.030 [70038]	|∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  0.060 [11351]	|∎∎∎∎∎∎
  0.090 [15564]	|∎∎∎∎∎∎∎∎∎
  0.120 [3035]	|∎∎
  0.150 [3]	|
  0.180 [6]	|
  0.210 [1]	|
  0.240 [0]	|
  0.270 [0]	|
  0.300 [1]	|

Latency distribution:
  10% in 0.0012 secs
  25% in 0.0017 secs
  50% in 0.0030 secs
  75% in 0.0534 secs
  90% in 0.0774 secs
  95% in 0.0793 secs
  99% in 0.0968 secs

Details (average, fastest, slowest):
  DNS+dialup:	 0.0000 secs, 0.0000 secs, 0.0070 secs
  DNS-lookup:	 0.0000 secs, 0.0000 secs, 0.0054 secs
  req write:	 0.0000 secs, 0.0000 secs, 0.0078 secs
  resp wait:	 0.0224 secs, 0.0001 secs, 0.3004 secs
  resp read:	 0.0001 secs, 0.0000 secs, 0.0129 secs

Status code distribution:
  [202]	100000 responses

The good news is this is not something going on with the kube-proxy. The bad news is it's actually an Ambassador issue.

Hey @plombardi89 sorry for the config drift. I've tested several scenarios and I forgot to change it back. Every time there is an Envoy config change the requests will fail for a short period of time, no matter the change, be it weight, headers, method or just adding a new mapping for a new backend.

@stefanprodan No worries. Spent a chunk of today digging in on this. We have some hypotheses so next steps are to test them out. Stay tuned! :)

@stefanprodan We dug into this rather a bit, with the end result that https://github.com/envoyproxy/envoy/issues/2776 is open now. We'll keep you posted!

@stefanprodan I've been looking into this in Envoy, and it looks like a major part of what we're seeing is that Envoy uses a probabilistic algorithm to decide when an HTTP connection should be drained. If you lengthen the drain time, it has more chances to decide to drain the connection.
So while lengthening the drain time isn't a panacea, it will reduce the number of drops you see. You can control the times with the environment variables AMBASSADOR_DRAIN_TIME and AMBASSADOR_SHUTDOWN_TIME.
The drain time (AMBASSADOR_DRAIN_TIME) is how long Envoy will wait for a connection to drop on its own before summarily closing it. The shutdown time (AMBASSADOR_SHUTDOWN_TIME) is the point at which the old Envoy process exists. AMBASSADOR_SHUTDOWN_TIME should always be greater than AMBASSADOR_DRAIN_TIME -- maybe start with AMBASSADOR_DRAIN_TIME 10 and AMBASSADOR_SHUTDOWN_TIME 15, and see how things behave.

We're closing this because it does not look like an Ambassador issue at this time and the solution according to the Envoy folks is to uptune the drain and shutdown time. That feedback also meshes with our load testing experience and setting higher times in which case connection failures drop dramatically by using more conservative numbers (in our case 60 seconds for  drain and 90 seconds for shutdown). Please open a new issue if you run into further connection drops.


[11.x] Added model loaded event

Added model loaded event that runs after the relations gets eager loaded to avoid N + 1 query issues when using relations in retrieved event because retrieved is called before relations gets eager loaded.
Considered adding new event rather than changing the retrieved event call place to avoid breaking any existing code.

Hi. How about the query->with() way of loading the relations?
Also pls define new functions/attributes with typed params and return types as stated by laravel https://redberry.international/laravel-10-features-and-updates/#mcetoc_1hfrpmpr11v

Thanks for your pull request to Laravel!
Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.
If applicable, please consider releasing your code as a package so that the community can still take advantage of your contributions!


Build fails with a long path

Sample
NativeModuleSample
Problem Description
I am receiving this error for a missing Windows.ApplicationModel.Appointments.AppointmentsProvider.2.h
Has anyone encountered it ?
`PS C:\project\react-native-windows-samples-main\samples\NativeModuleSample\csharp> npx react-native run-windows --no-deploy --no-launch --no-packager --no-autolink --proj "NativeModuleSample\NativeModuleSample.vsproj"
MSBuild version 17.3.1+2badb37d1 for .NET Framework
Building the projects in this solution one at a time. To enable parallel build, please add the "-m" switch.
Build started 10/5/2022 3:51:18 PM.
Project "C:\project\react-native-windows-samples-main\samples\NativeModuleSample\csharp\windows\NativeModuleSample.sln" on node 1 (Restore target(s)).
ValidateSolutionConfiguration:
Building solution configuration "Debug|x64".
_GetAllRestoreProjectPathItems:
Determining projects to restore...
Restore:
X.509 certificate chain validation will use the default trust store selected by .NET.
Done Building Project "C:\project\react-native-windows-samples-main\samples\NativeModuleSample\csharp\windows\NativeModuleSample.sln" (Restore target(s)).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:01.50
√ Restoring NuGet packages
i Autolink step is skipped
√ Found Solution: C:\project\react-native-windows-samples-main\samples\NativeModuleSample\csharp\windows\NativeModuleSample.sln
i Build configuration: Debug
i Build platform: x64
× Building Solution: Microsoft.ReactNative.Managed.CodeGen -> C:\project\react-native-windows-samples-main\sampl...
× Build failed with message C:\project\react-native-windows-samples-main\samples\NativeModuleSample\csharp\node_modules\react-native-windows\Microsoft.ReactNative\build\x64\Debug\Microsoft.ReactNative\Generated Files\winrt\Windows.ApplicationModel.Activation.h(10,10): fatal  error C1083: Cannot open include file: 'winrt/impl/Windows.ApplicationModel.Appointments.AppointmentsProvider.2.h': No such file or directory (compiling source file CoreApp.cpp) [C:\project\react-native-windows-samples-main\samples\NativeModuleSample\csharp\node_modules\react-native-windows\Microsoft.ReactNative\Microsoft.ReactNative.vcxproj]. Check your build configuration.
Command failed. Re-run the command with --logging for more information.`
My OS: Windows 10 version 21H1 Build(19043.2006)
Steps To Reproduce

download https://github.com/microsoft/react-native-windows-samples/tree/main/samples/NativeModuleSample
from command prompt go to the samples/NativeModuleSample directory
run npm install it works
run npx react-native run-windows --no-deploy --no-launch --no-packager --no-autolink --proj "NativeModuleSample\NativeModuleSample.vsproj"
it throws the said error then.

Expected Results
No response
CLI version
9.1.3
Environment
info Fetching system and libraries information...
System:
    OS: Windows 10 10.0.19043
    CPU: (4) x64 Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
    Memory: 4.93 GB / 11.89 GB
  Binaries:
    Node: 18.9.0 - C:\nodejs\node.EXE
    Yarn: 1.22.19 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 8.19.1 - C:\nodejs\npm.CMD
    Watchman: Not Found
  SDKs:
    Android SDK:
      API Levels: 31, 32
      Build Tools: 30.0.3, 31.0.0
      System Images: android-31 | Google APIs Intel x86 Atom_64, android-31 | Google Play Intel x86 Atom_64
      Android NDK: 22.1.7171670
    Windows SDK:
      AllowDevelopmentWithoutDevLicense: Enabled
      AllowAllTrustedApps: Enabled
  IDEs:
    Android Studio: Not Found
    Visual Studio: 16.11.32901.82 (Visual Studio Community 2019)
  Languages:
    Java: <IP_ADDRESS> - C:\Program Files\Eclipse Adoptium\jdk-<IP_ADDRESS>-hotspot\bin\javac.EXE
  npmPackages:
    @react-native-community/cli: Not Found
    react: 18.1.0 => 18.1.0
    react-native: 0.70.0 => 0.70.0
    react-native-windows: 0.70.2 => 0.70.2
  npmGlobalPackages:
    *react-native*: Not Found
info React Native v0.70.2 is now available (your project is running on v0.70.0).
info Changelog: https://github.com/facebook/react-native/releases/tag/v0.70.2
info Diff: https://react-native-community.github.io/upgrade-helper/?from=0.70.0
info To upgrade, run "react-native upgrade".

Target Platform Version
10.0.19041
Target Device(s)
Desktop
Visual Studio Version
Visual Studio 2019
Build Configuration
No response

@asklar Thank you for your quick reply.
However the error is still there with long paths turned on.
I dont really have that file winrt/impl/Windows.ApplicationModel.Appointments.AppointmentsProvider.2.h
however the winrt/impl/Windows.ApplicationModel.Appointments.AppointmentsProvider.h file is present in build directory after I run that command
`PS E:\projects\windows\react-native-windows-samples\samples\NativeModuleSample\csharp> Set-ExecutionPolicy Unrestricted -Scope Process -Force;

iex (New-Object System.Net.WebClient).DownloadString('https://aka.ms/rnw-deps.ps1')
Checking Free space on C: > 15 GB                            OK
Checking Installed memory >= 16 GB                Failed (warn)
Checking Windows version > 10.0.16299.0                      OK
Checking Developer mode is on                                OK
Checking Long path support is enabled                        OK
Checking Choco                                               OK
Checking git                                                 OK
Checking Compilers, build tools, SDKs and Visual Studio      OK
Checking NodeJS LTS                                          OK
Checking Chrome                                              OK
Checking Yarn                                                OK
Checking .net core 3.1                                       OK
All mandatory requirements met`

Ok, can you put the root of the repo higher up (e.g. E:\rnws\... instead of under E:\projects\windows\react-native-windows-samples)?
You may have to clean the build output first to get the tooling to generate some of the files that weren't generated due to long paths. To do this either open your project in Visual Studio, click on Build->Clean, or simply re-clone the repo higher up in the drive.

@asklar I confirm that reducing path length makes it work.
Thank you very much for your time.


Are Conventional Commits Supported?

I just setup our repo with this app, thank you for making it. 👍
One thing I noticed, however, is that it seems conventional commit messages retain their conventions:

Perhaps I am doing something wrong?  I'm learning a lot here lately, so could be overlooking something obvious.
Ideally, it would be great to have the messages captured to have those scrubbed for human readability.
Thank you for any assistance you can provide!

It's not supported by Release Drafter out of the box. Not an ideal solution, but maybe you can do this with the replacers functionality?

Turns out that this is OK!  I was drinking from the firehose there for a bit. 😆  The PR Labeler and Create Issue Branch appeared to use CC (as you know 😁), but you can configure them to use your own labels and any convention you want, really. 👍
Thank you for your reply and suggestion!


Passing headers. VScode to Colab Enterprise/JupyterLab with authentication + CORS

Currently I want to connect VScode with JupyterLab extension to Google Cloud Colab Enterprise or AI Notebooks or any JupyterLab service that requies authentication.
I'm currently using JupyterLab Gateway as a way to overwrite headers (Authentication + CORS - Origin). Is there a way to overwrite HTTP headers in current Extension? If not what is the any good pointers for me to add support for this.
Background:

https://github.com/jupyter-server/jupyter_server/issues/1439
https://medium.com/@gogasca_/how-to-connect-from-vscode-to-vertex-notebooks-directly-8c078d538b0b

Wanted behavior:
Ability to pass custom HTTP header for HTTP(s) and Websockets. Example:
headers = {"Origin": PROXY_URL, "Authentication": AUTH_TOKEN}

Some headers like Authentication can be regenerated every X seconds. (Using an external command gcloud)

I would like to see how can I add this to Extension properties. Any pointer will be appreciated

@DonJayamanne any pointers are appreciated. I would be happy to propose a PR. Thanks

@gogasca Thanks for filing this issue.
At this stage we have no plans on supporting such a feature request.
However you can create your own extension that passes the necessary headers and the like.
Please have a look at the Jupyter Hub extension that we've created.
This is a simple extension that takes care of auth and the like (with custom headers).
https://github.com/microsoft/vscode-jupyter-hub
Feel free to reach out for additional details with regards to this extension or the like


Update pyyaml version

Closes #70230
It updates the  PyYaml version from 5.1 to 6. The 5.1 version has security vulnerabilities as described in these links:

https://vulners.com/github/GHSA-3PQX-4FQF-J49F
https://vulners.com/osv/OSV:PYSEC-2020-96
https://vulners.com/osv/OSV:PYSEC-2021-142

Hey @galak, I changed the commit for being compliant with checks, should I do something to trigger the job?

As a first-time contributor, you just need to wait for one of the project's collaborators to trigger it, which I just did. Thanks!

Hey @galak, I changed the commit for being compliant with checks, should I do something to trigger the job?

As a first-time contributor, you just need to wait for one of the project's collaborators to trigger it, which I just did. Thanks!

Thank you very much @kartben, I appreciate that!!

hey @kartben, is there any way for testing the commits message compliance locally?

there is!
~/zephyrproject/zephyr/scripts/ci/check_compliance.py

hey @kartben, I appreciate your help! I think it is compliant now.

I don't understand why the Documentation Build is failing :/

I don't understand why the Documentation Build is failing :/

I re-ran the job -- random issue with the Github runner is my guess.

I don't understand why the Documentation Build is failing :/

I re-ran the job -- random issue with the Github runner is my guess.

Awesome! Thank you very much!

@aescolar @nashif as release managers, please consider re-assigning this one to either of you and merging. Thanks!


HBASE-28638 Impose retry limit for specific errors to recover from remote procedure failure using server crash

Jira: HBASE-28638
Master initiated remote procedures are scheduled by RSProcedureDispatcher. If it encounters specific errors on first retry (e.g. CallQueueTooBigException or SaslException), it is guaranteed that the remote call has not reached the regionserver, therefore the remote call is marked failed prompting the parent procedure to select different target regionserver to resume the operation.
If the first attempt is successful, RSProcedureDispatcher continues with infinite retries. We can encounter valid case (e.g. ConnectionClosedException) which is halting the remote operation. Without manual intervention, it can cause significant delay upto several minutes or hours to the region-in-transition.
The purpose of this Jira is to impose retry limit for specific error types such that if the retry limit is reached, the master can recover the state of the ongoing remote call failure by initiating SCP (ServerCrashProcedure) on the target server. The SCP is going to override the TRSP (TransitRegionStateProcedure) if required. This can ensure that the target server has no region hosted online before we suspend the ongoing TRSP.
Scheduling SCP for the target server will always lead to the regionserver in stopped state. Either regionserver would be automatically stopped, or if the regionserver is able to send the region report to master, master will reject it, which will further lead to regionserver abort.
Changes proposed:

Allow extending RSProcedureDispatcher
RSProcedureDispatcher can impose retry limit for specific errors:

CallQueueTooBigException
SaslException
ConnectionClosedException

Default retry limit: 5
If retry limit is exhausted, schedule recovery through server crash. Let SCP override current procedure state.
Tests for ConnectionClosedException

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 36s

Docker mode activated.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
3m 41s

the patch passed

+1 :green_heart:
compile
3m 45s

the patch passed

+1 :green_heart:
javac
3m 45s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 47s

the patch passed

+1 :green_heart:
spotbugs
2m 16s

the patch passed

+1 :green_heart:
hadoopcheck
13m 38s

Patch does not cause any errors with Hadoop 3.3.6 3.4.0.

+1 :green_heart:
spotless
1m  4s

patch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 51s

the patch passed

+1 :green_heart:
compile
0m 53s

the patch passed

+1 :green_heart:
javac
0m 53s

the patch passed

+1 :green_heart:
javadoc
0m 26s

the patch passed

+1 :green_heart:
shadedjars
5m 36s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

-1 :x:
unit
230m 42s
/patch-unit-hbase-server.txt
hbase-server in the patch failed.

255m 28s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/1/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6462

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux 5c8093dec320 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / c70332d9909c5f4df6f58d264c89ce527cd097ba

Default Java
Eclipse Adoptium-17.0.11+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/1/testReport/

Max. process+thread count
5022 (vs. ulimit of 30000)

modules
C: hbase-server U: hbase-server

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/1/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 32s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ master Compile Tests _

+1 :green_heart:
mvninstall
3m 32s

master passed

+1 :green_heart:
compile
3m  8s

master passed

+1 :green_heart:
checkstyle
0m 36s

master passed

+1 :green_heart:
spotbugs
1m 40s

master passed

+1 :green_heart:
spotless
0m 47s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
3m 43s

the patch passed

+1 :green_heart:
compile
3m 36s

the patch passed

+1 :green_heart:
javac
3m 36s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 43s

the patch passed

+1 :green_heart:
spotbugs
2m  1s

the patch passed

+1 :green_heart:
hadoopcheck
13m 27s

Patch does not cause any errors with Hadoop 3.3.6 3.4.0.

+1 :green_heart:
spotless
0m 57s

patch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 59s

the patch passed

+1 :green_heart:
compile
0m 58s

the patch passed

+1 :green_heart:
javac
0m 58s

the patch passed

+1 :green_heart:
javadoc
0m 29s

the patch passed

+1 :green_heart:
shadedjars
5m 18s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

-1 :x:
unit
233m 45s
/patch-unit-hbase-server.txt
hbase-server in the patch failed.

259m  3s

Subsystem
Report/Notes

Docker
ClientAPI=1.47 ServerAPI=1.47 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/2/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6462

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux 96ffd468c85d 5.4.0-200-generic #220-Ubuntu SMP Fri Sep 27 13:19:16 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / a55b88f28f4db80eac07560afb60946d25c698ec

Default Java
Eclipse Adoptium-17.0.11+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/2/testReport/

Max. process+thread count
5437 (vs. ulimit of 30000)

modules
C: hbase-server U: hbase-server

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/2/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

Why do we need a new implementation of RSProcedureDispatcher?
I think here we can introduce a retry limit, by default it is -1, which means infinite retry, which keeps the old behavior, and if set to a positive value, we will schedule SCP when reaching the limit?

Why do we need a new implementation of RSProcedureDispatcher?

It is done only for testing purpose. There is no new implementation as part of the source code.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
3m 37s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ master Compile Tests _

+1 :green_heart:
mvninstall
2m 52s

master passed

+1 :green_heart:
compile
2m 56s

master passed

+1 :green_heart:
checkstyle
0m 38s

master passed

+1 :green_heart:
spotbugs
1m 33s

master passed

+1 :green_heart:
spotless
0m 46s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 54s

the patch passed

+1 :green_heart:
compile
2m 53s

the patch passed

+1 :green_heart:
javac
2m 53s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 39s

the patch passed

+1 :green_heart:
spotbugs
1m 39s

the patch passed

+1 :green_heart:
hadoopcheck
10m 27s

Patch does not cause any errors with Hadoop 3.3.6 3.4.0.

+1 :green_heart:
spotless
0m 43s

patch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 50s

the patch passed

+1 :green_heart:
compile
0m 56s

the patch passed

+1 :green_heart:
javac
0m 56s

the patch passed

+1 :green_heart:
javadoc
0m 26s

the patch passed

+1 :green_heart:
shadedjars
5m 37s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

-1 :x:
unit
211m 14s
/patch-unit-hbase-server.txt
hbase-server in the patch failed.

237m 48s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/3/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6462

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux 4863f8ad39a4 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 6aa56e77566d24959e072dd8b452c6df3d27ebb3

Default Java
Eclipse Adoptium-17.0.11+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/3/testReport/

Max. process+thread count
5393 (vs. ulimit of 30000)

modules
C: hbase-server U: hbase-server

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/3/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 38s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ master Compile Tests _

+1 :green_heart:
mvninstall
3m  2s

master passed

+1 :green_heart:
compile
2m 58s

master passed

+1 :green_heart:
checkstyle
0m 38s

master passed

+1 :green_heart:
spotbugs
1m 36s

master passed

+1 :green_heart:
spotless
0m 44s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 52s

the patch passed

+1 :green_heart:
compile
2m 55s

the patch passed

+1 :green_heart:
javac
2m 55s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 38s

the patch passed

+1 :green_heart:
spotbugs
1m 45s

the patch passed

+1 :green_heart:
hadoopcheck
10m 19s

Patch does not cause any errors with Hadoop 3.3.6 3.4.0.

+1 :green_heart:
spotless
1m  9s

patch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 51s

the patch passed

+1 :green_heart:
compile
0m 53s

the patch passed

+1 :green_heart:
javac
0m 53s

the patch passed

+1 :green_heart:
javadoc
0m 26s

the patch passed

+1 :green_heart:
shadedjars
5m 35s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

+1 :green_heart:
unit
209m 25s

hbase-server in the patch passed.

233m 56s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/4/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6462

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux e587864c4152 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 6aa56e77566d24959e072dd8b452c6df3d27ebb3

Default Java
Eclipse Adoptium-17.0.11+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/4/testReport/

Max. process+thread count
5628 (vs. ulimit of 30000)

modules
C: hbase-server U: hbase-server

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/4/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 35s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ master Compile Tests _

+1 :green_heart:
mvninstall
2m 46s

master passed

+1 :green_heart:
compile
2m 35s

master passed

+1 :green_heart:
checkstyle
0m 34s

master passed

+1 :green_heart:
spotbugs
1m 33s

master passed

+1 :green_heart:
spotless
0m 42s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 37s

the patch passed

+1 :green_heart:
compile
2m 34s

the patch passed

+1 :green_heart:
javac
2m 34s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 34s

the patch passed

+1 :green_heart:
spotbugs
1m 31s

the patch passed

+1 :green_heart:
hadoopcheck
9m 27s

Patch does not cause any errors with Hadoop 3.3.6 3.4.0.

+1 :green_heart:
spotless
0m 40s

patch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 53s

the patch passed

+1 :green_heart:
compile
0m 54s

the patch passed

+1 :green_heart:
javac
0m 54s

the patch passed

+1 :green_heart:
javadoc
0m 26s

the patch passed

+1 :green_heart:
shadedjars
5m 39s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

-1 :x:
unit
21m 20s
/patch-unit-hbase-server.txt
hbase-server in the patch failed.

43m 53s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/5/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6462

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux 606bbca932d1 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / c644ba85c050431847768a9335212b4fceec20b8

Default Java
Eclipse Adoptium-17.0.11+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/5/testReport/

Max. process+thread count
2180 (vs. ulimit of 30000)

modules
C: hbase-server U: hbase-server

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/5/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 40s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ master Compile Tests _

+1 :green_heart:
mvninstall
2m 52s

master passed

+1 :green_heart:
compile
3m 46s

master passed

+1 :green_heart:
checkstyle
0m 54s

master passed

+1 :green_heart:
spotbugs
1m 49s

master passed

+1 :green_heart:
spotless
0m 42s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
3m 32s

the patch passed

+1 :green_heart:
compile
2m 52s

the patch passed

+1 :green_heart:
javac
2m 52s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 34s

the patch passed

+1 :green_heart:
spotbugs
1m 39s

the patch passed

+1 :green_heart:
hadoopcheck
10m 59s

Patch does not cause any errors with Hadoop 3.3.6 3.4.0.

+1 :green_heart:
spotless
0m 40s

patch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 48s

the patch passed

+1 :green_heart:
compile
0m 53s

the patch passed

+1 :green_heart:
javac
0m 53s

the patch passed

+1 :green_heart:
javadoc
0m 26s

the patch passed

+1 :green_heart:
shadedjars
5m 40s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

-1 :x:
unit
21m 16s
/patch-unit-hbase-server.txt
hbase-server in the patch failed.

42m 51s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/6/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6462

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux 910e25b0059c 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 87b6585d895e27fe4604a9514fb4129361c9b144

Default Java
Eclipse Adoptium-17.0.11+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/6/testReport/

Max. process+thread count
2165 (vs. ulimit of 30000)

modules
C: hbase-server U: hbase-server

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/6/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 36s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ master Compile Tests _

+1 :green_heart:
mvninstall
2m 44s

master passed

+1 :green_heart:
compile
2m 36s

master passed

+1 :green_heart:
checkstyle
0m 34s

master passed

+1 :green_heart:
spotbugs
1m 29s

master passed

+1 :green_heart:
spotless
0m 39s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 34s

the patch passed

+1 :green_heart:
compile
2m 32s

the patch passed

+1 :green_heart:
javac
2m 32s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 35s

the patch passed

+1 :green_heart:
spotbugs
1m 32s

the patch passed

+1 :green_heart:
hadoopcheck
9m 20s

Patch does not cause any errors with Hadoop 3.3.6 3.4.0.

+1 :green_heart:
spotless
0m 39s

patch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 52s

the patch passed

+1 :green_heart:
compile
0m 53s

the patch passed

+1 :green_heart:
javac
0m 53s

the patch passed

+1 :green_heart:
javadoc
0m 25s

the patch passed

+1 :green_heart:
shadedjars
5m 38s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

+1 :green_heart:
unit
184m 25s

hbase-server in the patch passed.

209m 21s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/7/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6462

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux 8a782b85b501 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 0628291c7459b0c72182bfeb9f1b8930f28154af

Default Java
Eclipse Adoptium-17.0.11+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/7/testReport/

Max. process+thread count
5029 (vs. ulimit of 30000)

modules
C: hbase-server U: hbase-server

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/7/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 36s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ master Compile Tests _

+1 :green_heart:
mvninstall
3m  2s

master passed

+1 :green_heart:
compile
2m 40s

master passed

+1 :green_heart:
checkstyle
0m 36s

master passed

+1 :green_heart:
spotbugs
1m 34s

master passed

+1 :green_heart:
spotless
0m 39s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 52s

the patch passed

+1 :green_heart:
compile
3m  5s

the patch passed

+1 :green_heart:
javac
3m  5s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 34s

the patch passed

+1 :green_heart:
spotbugs
1m 34s

the patch passed

+1 :green_heart:
hadoopcheck
9m 44s

Patch does not cause any errors with Hadoop 3.3.6 3.4.0.

+1 :green_heart:
spotless
0m 39s

patch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 54s

the patch passed

+1 :green_heart:
compile
0m 54s

the patch passed

+1 :green_heart:
javac
0m 54s

the patch passed

+1 :green_heart:
javadoc
0m 26s

the patch passed

+1 :green_heart:
shadedjars
5m 37s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

-1 :x:
unit
179m 33s
/patch-unit-hbase-server.txt
hbase-server in the patch failed.

204m  4s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/8/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6462

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux a683c22e0d9d 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / f8fd6b9c956017afc053381900574ba9fdaef3d0

Default Java
Eclipse Adoptium-17.0.11+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/8/testReport/

Max. process+thread count
5137 (vs. ulimit of 30000)

modules
C: hbase-server U: hbase-server

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6462/8/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.