2.4.0 not pick up IngressRoute CRD ?

Do you want to request a feature or report a bug?

Bug

What did you do?
Upgrade traefik from 2.3.7 to 2.4.0 using helm charts
What did you expect to see?
everything running well
What did you see instead?
My endpoint becomes 404 status, and when I looking the dashboard, all my IngressRouete CRD were disappeared,
(But using kubectl command to get ingressroute, it still there.)
Seems like traefik 2.4.0 didn't pick up the ingressroute crd.
But everything working well when I downgrade back to 2.3.7
Is there anything I missed?
PS. I also try to add the newest ServersTransport crd with IngreeRoute, but still got 404.
Output of traefik version: (What version of Traefik are you using?)
2.4.0

What is your environment & configuration (arguments, toml, provider, platform, ...)?
globalArguments:
  - "--global.checknewversion"
  - "--global.sendanonymoususage"
  - "--api.insecure=true"
  - "--metrics=true"
  - "--metrics.prometheus=true"
  - "--ping.entryPoint=web"
  - "--entryPoints.web.forwardedHeaders.insecure"
  - "--providers.kubernetesingress=true"

additionalArguments:
  - '--providers.kubernetesingress.ingressclass="traefik"'
  - "--providers.kubernetescrd.labelselector=traefik=traefik"

others using default from charts
If applicable, please paste the log output in DEBUG level (--log.level=DEBUG switch)
{"ClientAddr":"<IP_ADDRESS>:1234","ClientHost":"<IP_ADDRESS>","ClientPort":"51350","ClientUsername":"-","DownstreamContentSize":19,"DownstreamStatus":404,"Duration":85981,"OriginContentSize":19,"OriginDuration":21555,"OriginStatus":404,"Overhead":64426,"RequestAddr":"www.example.com","RequestContentSize":0,"RequestCount":30,"RequestHost":"www.example.com","RequestMethod":"GET","RequestPath":"/","RequestPort":"-","RequestProtocol":"HTTP/1.1","RequestScheme":"http","RetryAttempts":0,"StartLocal":"2021-02-01T08:11:42.626276514Z","StartUTC":"2021-02-01T08:11:42.626276514Z","entryPointName":"web","level":"info","msg":"","request_User-Agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:85.0) Gecko/20100101 Firefox/85.0","time":"2021-02-01T08:11:42Z"}

Same here: https://github.com/traefik/traefik-helm-chart/issues/345

Hey 👋
Sorry for the issues you have. Are you sure, you applied the correct (new) CRD Definitions? I suspect the issue is coming from not having all CRDs properly in place. Its linked to #344

After manually applying servertransports crds you have to delete traefik pod(s) to restart it, otherwise you will continue to get 404s.

So I can close that one? :)

Hi:
I'm sure the servertransports crds has been applyed. but I didn't restart traefik pod.
I think that is my problem.
Thank you.


feature/value list

A key value list component to display key value pairs.

👋 Thanks for creating a pull request! 🚀 Checkout the storybooks we've created for it: chlorophyllreact


Improve UI of HashLock TransactionGraphic

Move transactionType under the arrow. Duration can be placed in the popup or under LockIcon

looks okay to me


Image Preview is not working when Link thumbnail to PhotoSwipe slideshow is enabled

When I enable Link thumbnail to PhotoSwipe slideshow, the plugin "Image Preview" is not working anymore.
The click tap event (template/index.tpl) seems to mess with Image Preview in some way.

Does it work if you change line 302 in template/index.tpl from
$(this).off().on('click tap', function(event) {

to
$(this).off('click tap').on('click tap', function(event) {

?
It looks like imgPreview attaches mousemove/hover events, so above could help. Having both link to photoswipe AND imgPreview could cause some real mess on mobile devices though.

It works! Thanks. On Android, I do not have any problem.
And congratulations for your great theme!

Great. Will be in next version.


Remove localization from formatting coordinates

Per https://github.com/commons-app/apps-android-commons/issues/289#issuecomment-294382949

Looks good, thanks!


feat(DTFS2-6113): add pagination to TFM deals and facilities

Introduction :pencil2:
PR to merge pagination feature branch into main.
Resolution :heavy_check_mark:
This PR contains the following PRs, all of which have already passed review:

DTFS2-6931
DTFS2-6932
DTFS2-6935
DTFS2-6933

Codecov Report
Attention: Patch coverage is 68.60987% with 70 lines in your changes are missing coverage. Please review.

Project coverage is 32.29%. Comparing base (fbe7ec4) to head (851dd1a).
Report is 114 commits behind head on main.

Files
Patch %
Lines

...1/controllers/tfm/deal/tfm-get-deals.controller.js
0.00%
30 Missing and 5 partials :warning:

...lers/tfm/facility/tfm-get-facilities.controller.js
0.00%
16 Missing and 6 partials :warning:

...-manager-api/src/v1/controllers/deal.controller.js
0.00%
7 Missing :warning:

...ager-api/src/v1/controllers/facility.controller.js
0.00%
2 Missing :warning:

...r/controllers/helpers/dealsAndFacilities.helper.js
97.56%
2 Missing :warning:

dtfs-central-api/src/mapping/mapDataModel.js
0.00%
1 Missing :warning:

.../src/utils/getObjectPropertyValueFromStringPath.js
0.00%
0 Missing and 1 partial :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2921      +/-   ##
==========================================
+ Coverage   22.57%   32.29%   +9.71%
==========================================
  Files        1136     1342     +206
  Lines       27255    30633    +3378
  Branches     4486     4947     +461
==========================================
+ Hits         6153     9892    +3739
+ Misses      18388    18092     -296
+ Partials     2714     2649      -65

Flag
Coverage Δ

api-test
0.40% <ø> (-0.09%)
:arrow_down:

ui-test
?

unit-test
32.55% <68.60%> (+27.91%)
:arrow_up:

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.


Console output not correctly shown while Debugging

Issue Type: Bug
Hi,
I encountered an issue while debegging whereby any values pushed to console would not be printed until the cursor moves to next line.
The issue persists both with integrated as well as external terminal. Windows version of code-insiders does not have the same problem.
I also noticed that the 'step into' feature works differently from Windows and does not actually step into any of the header files like <iostream>.
Let me know if you need any further information.

What debugger are you using?

GCC. I have provided the task.json and launch.json below:
/home/ali/Documents/Visual Studio Code/CPP/Project 2/.vscode/tasks.json
/home/ali/Documents/Visual Studio Code/CPP/Project 2/.vscode/launch.json

/extCpp


not_line_ending1?

I've run into a problem with using nom::character::complete::not_line_ending to match the entire contents of a line up to the line-ending. It works well in isolation, but using nom::multi::many{1|0} to parse multiple lines fails unexpectedly. As far as I can tell, this is because not_line_ending can successfully match on empty input, prompting many{1|0} to error out rather than infinite looping. I was initially under the impression that not_line_ending would behave like not_line_ending1 (requiring at least one matching character) since there aren't {1|0} variants, but it actually behaves like not_line_ending0.
I thought that wrapping the parser in a terminated that checked for line-ending or EOF
I'm considering a take_till1 that matches on a hand-rolled is_line_ending predicate (since nom::character::is_newline doesn't work on file input from Windows), but the custom logic inside not_line_ending gave me pause. I assume there is some kind of performance/subtle-correctness reason that it's not implemented with take_till (or some suitable combinator) that I haven't logic'd through completely enough.
Prerequisites
Here are a few things you should provide to help me understand the issue:

Rust version : 1.47.0
nom version : 6.0.0
nom compilation features used: default

Test case
Please provide a short, complete (with crate import, etc) test case for
the issue, showing clearly the expected and obtained results.
Example test case:
use nom::error::{Error, ErrorKind, ParseError};
use nom::character::complete as nom_character;

pub fn eof<T, E: ParseError<T>>(input: T) -> IResult<T, (), E>
where
    T: InputIter + InputLength + Slice<RangeFrom<usize>>,
    <T as InputIter>::Item: AsChar,
{
    let mut it = input.iter_indices();
    match it.next() {
        Some(_) => Err(Err::Error(E::from_error_kind(input, ErrorKind::Eof))),
        None => Ok((input, ())),
    }
}

pub fn eof_or_line_ending<T, E: ParseError<T>>(input: T) -> IResult<T, (), E>
where
    T: Clone
        + InputIter
        + InputLength
        + Slice<Range<usize>>
        + Slice<RangeFrom<usize>>
        + Compare<&'static str>
        + Slice<RangeTo<usize>>,
    <T as InputIter>::Item: AsChar,
{
    nom::branch::alt((
        eof,
        nom::combinator::map(nom_character::line_ending, |_| ()),
    ))(input)
}

fn unknown(input: &str) -> IResult<&str, &str> {
    nom_character::not_line_ending(input)
}

#[derive(Clone, Debug, PartialEq)]
pub struct UnknownLine<'a>(pub &'a str);

fn unknown_line(input: &str) -> IResult<&str, UnknownLine> {
    nom::combinator::map(
        nom::sequence::terminated(unknown, eof_or_line_ending),
        UnknownLine,
    )(input)
}

pub fn parser(input: &str) -> IResult<&str, Vec<UnknownLine>> {
    nom::multi::many0(unknown_line)(input)
}

let input = "Foo Bar\r\nBaz\r\nWow Everything Is Awesome";

fn main() {
  let res = vec![
    UnknownLine("Foo Bar"),
    UnknownLine("Baz"),
    UnknownLine("Wow Everything Is Awesome"),
  ];
  assert_eq!(
    parser(input),
    Ok(("", res))
  ); // returns Err::Error(Error::from_error_kind("", ErrorKind::Many0))
}

Ok, decided to go a bit lower-level. Is this a dumb way to write a match1 combinator?
#[derive(Debug)]
#[derive(Error)]
#[error("Parser matched a zero-length sequence")]
pub struct EmptyMatchError;

pub fn match1<I, O, F, E>(mut parser: F) -> impl Parser<I, O, E>
where
    I: Clone + PartialEq,
    F: Parser<I, O, E>,
    E: FromExternalError<I, EmptyMatchError>
{
    move |input: I| {
        let i = input.clone();
        let (input, o) = parser.parse(input)?;
        if i != input {
          Ok((input, o))
        } else {
          Err(Err::Error(E::from_external_error(i, ErrorKind::MapRes, EmptyMatchError)))
        }
      }
}


Add session storage

I don't know why Scrutinizer gave up. Can you restart the inspection?

Scrutinizer doesn't really work with 7 yet: no worries (it will keep crashing for another few days)

Note: regardless of scrutinizer, we can't commit an interface before we see working code based on it (or else we build ourselves a maintenance trap)

Are you talking about a specifig interface?

@Ocramius you mean more than my file implementation?

Yup. Won't commit an interface until we have a working implementation for it as well

Implementation of what? Either I don't get what you mean or you didn't see that I've already committed an implementation.

Ah yes, didn't see that, sorry!

So what do you think of my implementation? Here are a few things I'd like to discuss:

Separate StorableSessionInterface that extends SessionInterface - is that a good idea or should we just modify SessionInterface?
The default StorableSession wrapping any StorageInterface object instead of extending the class
SessionIdInterface::__toString() as the way to get to the string value

@lcobucci can you take over review? I'll be swamped until Tuesday.
@MidnightDesign sorry for not coming back at you for this, I was distracted by a lot of other things these days :-(

@Ocramius Yeap I'll do it tonight ;)

@lcobucci Did you read my questions?

Separate StorableSessionInterface that extends SessionInterface - is that a good idea or should we just modify SessionInterface?
Right now, the session ID is created when the session is first persisted. Should this be done when it is instantiated?

I think that StorableSessionInterface could have more things that make it really "storable". Maybe adding methods like public function save(StorageInterface $storage) and public static function load(StorageInterface $storage, SessionIdInterface $id):StorableSessionInterface.
We actually don't change the session id so it would be better to make the ID mandatory and replace the setId() by something like public function regenerateId(StorageInterface $storage, bool $clear = false).

The default StorableSession wrapping any StorageInterface object instead of extending the class

I believe you wanted to say "The default StorableSession wrapping any SessionInterface", right? If so I think that keeping as a decorator gives us more flexibility.

SessionIdInterface::__toString() as the way to get to the string value

This is ok IMO.

What other implementations should I try next? I was thinking of a Doctrine adapter (using ObjectManager), but that would introduce a nasty require-dev + suggest dependency that should be in another package.

After a really small research I think that we could use something like the league/flysystem instead of writing/reading the files directly. This would allow people to use other adapters rather than the Local (there're some people storing session files in S3 or Azure).
I also suggest that storing using doctrine\cache would be also good.
Splitting packages is a good idea we just have to consider the complexity of managing all packages.

I'm a bit sleepy now so I had to edit my previous comment in order to give a good-ish suggestion :smile:

I think that we could add public static function fromStorage(StorageInterface $storage, SessionIdInterface $id):StorableSessionInterface, always have an ID

What exactly do you mean? Have this also act as a factory method and make the constructor private?

replace the setId() by something like public function regenerateId(StorageInterface $storage, bool $clear = false)

I would remove the setId() method in that case. Can you give me a use case for regenerating the ID? Security?

After a really small research I think that we could use something like the league/flysystem instead of writing/reading the files directly. This would allow people to use other adapters rather than the Local (there're some people willing to store session files in S3 or Azure).

I love league/flysystem, but that would also mean another dependency, even if people don't even use the file storage.

I also suggest that storing using doctrine/cache would be good.
Splitting packages is a good idea we just have to consider the complexity of managing all packages.

I get what you're saying, but I don't think that's not a problem if you need to install additional packages (...) in really prominent in the readme.

What exactly do you mean? Have this also act as a factory method and make the constructor private?

Yes, we can use a named constructors to make things more explicit (in that case we also need something to start a blank session).

I would remove the setId() method in that case. Can you give me a use case for regenerating the ID? Security?

IMHO the only reason to change the session ID is when you're trying to regenerate it. The ID regeneration prevents session fixation and session hijacking.

I love league/flysystem, but that would also mean another dependency, even if people don't even use the file storage.
I get what you're saying, but I don't think that's not a problem if you need to install additional packages (...) in really prominent in the readme.

Yeah I agree with you about that. When I said about the management complexity I meant also that would also be something interesting to consider to create an organisation to group all packages (but we need @Ocramius inputs on this), like:

php7session/middleware
php7session/storageless
php7session/file
php7session/cache
php7session/database

That may solve your suggest + dev dependencies and keeps the cohesion between the packages.

The file storage adapter can be provided OOTB, in my opinion

@lcobucci I just played around with that named constructors idea of yours and I have to say: I don't really think this will work.
What would StorageInterface::load() return? An instance of StoableSession? Then the StorableSession constructor would have to be public - which defeats the purpose of this change.
To be honest, I don't think it's a big deal if StorableSessionInterface::getId() can return null. It just means that the session hasn't been saved yet.
Another option that comes to my mind is to keep the constructor public, but still require an ID and a StorageInterface instance. Then the session could store itself upon changes (similar to what zendframework/zend-session does).

A named constructor can't be part of an interface, much like a normal
constructor can't either.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 20 January 2016 at 19:05, Rudolph Gottesheim<EMAIL_ADDRESS>wrote:

@lcobucci https://github.com/lcobucci I just played around with that
named constructors idea of yours and I have to say: I don't really think
this will work.
What would StorageInterface::load() return? An instance of StoableSession?
Then the StorableSession constructor would have to be public - which
defeats the purpose of this change.
To be honest, I don't think it's a big deal if
StorableSessionInterface::getId() can return null. It just means that the
session hasn't been saved yet.
Another option that comes to my mind is to keep the constructor public,
but still require an ID and a StorageInterface instance. Then the
session could store itself upon changes (similar to what
zendframework/zend-session https://github.com/zendframework/zend-session
does).
—
Reply to this email directly or view it on GitHub
https://github.com/Ocramius/PSR7Session/pull/30#issuecomment-173308076.

I don't think we were talking about adding them to the interface but to SessionStorage.

@MidnightDesign sorry, I read StorageInterface::load() and thought it was a static method (my bad, I usually differentiate via # and ::, while PHP usually does :: regardless).

Oh, okay. Thanks, I'll use # in the future.

I think StorageInterface#load() should throw an exception if the session could not be found. What do you think?

Don't think that would be a good idea: throwing exceptions there would allow a frontend user to brute-force the app, looking for valid sessions. Always returning a session (even an empty one) would be preferable.

In general, I am not too happy with the current implementation. If developers read "PHP file session", they will assume a certain behavior, and that is the one implemented in PHP natively. And the key feature of the native implementation is that PHP does solve the problem of race conditions by using file locks.
This implementation does not use locks. Instead, it will try to write the whole session data as soon as a single write call to the session object has been made. It is thus very likely to loose data when encountering concurrent requests for the same session id because there will be two independent copies of session data, which get altered and immediately everything gets written to disk. Also, one should discuss the performance impact of this solution.
A cookie based implementation will generally have the same problem - the winning data is the one sent to the browser last, overwriting any previous versions of the cookie. However, it does not ring any bells resembling a mechanism well known from the past that behaves differently in an important field. Also, you could work around this by separating the data into multiple cookies. And in general, you wouldn't send huge amounts of data via cookies, anyway, would you.

@SvenRtbg Thank you for your feedback.
I will add the LOCK_EX flag to the file_put_contents() call.
I am also not too happy about the dissonance between the save() and load() methods, but then StorableSession would need a constructor that accepts a SessionIdInterface to set the ID - which developes shouldn't use. The way I see it, developers shouldn't use the load() and save() methods themselves. Maybe I should add an @internal annotation to those methods?

It's been a while, but I'm picking this up again.
@Ocramius @lcobucci Do we want the session to save itself on every change? Or do we want the user to call save() on the storage explicitly? The former would be nicer to use, but the latter seems cleaner.

Storage adapters now return a new empty session when the session with the requested ID isn't found. Should the session have the requested ID or a new one?

At this point, I'd suggest moving this to a separate repo. @lcobucci @malukenho @necromant2005 how should we call it?

At this point, I'd suggest moving this to a separate repo. @lcobucci @malukenho @necromant2005 how should we call it?

psr7-sessions/filesystem?

 Filesystem is just a
detail, once storage is involved.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On Tue, Sep 27, 2016 at 7:48 PM, Luís Otávio Cobucci Oblonczyk <
<EMAIL_ADDRESS>wrote:

At this point, I'd suggest moving this to a separate repo. @lcobucci
https://github.com/lcobucci @malukenho https://github.com/malukenho
@necromant2005 https://github.com/necromant2005 how should we call it?
psr7-sessions/filesystem?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/psr7-sessions/storageless/pull/30#issuecomment-249942538,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJakGlfDrtX5Ceb6VYHHyMvL7uF15kKks5quVbZgaJpZM4GpZod
.

Thought so too when I saw the changes you have made in the last few months. I like "persistent".

 Filesystem is just a detail, once storage is involved.

But do we want to keep the code that stores things using the filesystem together with the code that uses a caching server?
I do like "persistent" but I think it would be better to have different packages for things that don't change together.

I do agree with @lcobucci. Just persistent is way too much abstract.

In my mind it's storageless <- persistent (including the filesystem adapter because why not) <- (storage adapters) where <- are the dependencies.

It may be too abstract, but we'd just provide a set of adapters:

filesystem adapter
doctrine DBAL adapter
cache adapter (not sure if we should endorse that)

Those would be additions to the project, after a first "filesystem-only" implementation, I suppose :-)

Ping @malukenho @lcobucci


Add 'United Kingdom' to the EU countries

As a client I want to export a shipment to the United Kingdom without having troubles with the restrictions of a world shipment.

This is fixed in the latest version.


chore(deps): update terraform github.com/terraform-ibm-modules/terraform-ibm-devsecops-alm to v1.0.2

This PR contains the following updates:

Package
Type
Update
Change

github.com/terraform-ibm-modules/terraform-ibm-devsecops-alm
module
patch
v1.0.1-beta.1 -> v1.0.2

Release Notes

terraform-ibm-modules/terraform-ibm-devsecops-alm
v1.0.2
Compare Source
Bug Fixes

deps: update terraform-module to v1.0.5 (#143) (eec930b)

v1.0.1
Compare Source
Bug Fixes

add link to ref arch doc (#147) (43fd66d)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

Edited/Blocked Notification
Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.
You can manually request rebase by checking the rebase/retry box above.
⚠ Warning: custom changes will be lost.

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


Support skipped tests from scheme file

Addresses issue #109 by adding support to read tests to exclude from the skipped tests in a given scheme.

@oliverhu please review

@lyndsey-ferguson , this is part of #71 and @ob is working on that one

@oliverhu is there a PR for that? I'd like to see if it provides the option to read the xcscheme file as that fits into our build system nicely.

no PR yet. That would read the skipped tests + env settings from the schemes.

Closing as this will be fixed as part of another issue.


Page objects rooted at elements

This is another solution to issue #263 This enhances page objects to have a root element. This root element can be any element in the DOM or the  node. All the tests over the functionality added from the other branch are in this branch too, but just using page objects instead of a separate section class. There is also a test for indexed properties, which doesn't work in the other branch.

Yeah!

How soon will this be released?


podmanv2 pod create using podspecgen

using the factory approach similar to container, we now create pods based on a pod spec generator.  wired up the podmanv2 pod create command, podcreatewithspec binding, simple binding test, and apiv2 endpoint.
also included some code refactoring as it introduced as easy circular import.
Signed-off-by: Brent Baude<EMAIL_ADDRESS>

I'm getting really uncomfortable with the amount of code duplication going on here - we're rapidly approaching the point where bugfixes are going to have to go into both Podman and Podmanv2, and making sure that happens is going to be painful.

Which is why we need to get rid of podman 1.0 ASAP.  We need to start a branch for 1.0 and then make master branch the 2.0 branch.

Which is why we need to get rid of podman 1.0 ASAP. We need to start a branch for 1.0 and then make master branch the 2.0 branch.

@rhatdan you couldnt be more right!

/approve
/lgtm
/hold

/hold cancel

/hold

/hold cancel


[Samples][Java] Fix disparities of 02.echo-bot sample

Related to microsoft/botbuilder-java#1165
Proposed Changes
We compared the documentation/code migration/behavior of the 02.echo-bot sample between Java and C# and we found disparities and fixes that this PR includes.

Update README
Send SSML parameter like C# sample
Clean-up autogenerated files/folder related to Eclipse (e.g. target/.classpath)
Add package-info.java file

Testing
Echo bot sample working as expected

Hi @tracyboehrer & @LeeParrishMSFT, we created this PR fixing some disparities that we found in the 02.echo-bot sample.


Export data to a db dump file

We need a way to export customer data to a SQL file that they can then upload and use to bootstrap their database with existing data.

@dmmiller what's the eta on that? will it also include where to get attachments from s3?

@daniel-white , ask and ye shall receive.  @flooey just posted an update here : https://github.com/getcord/cord-preview?tab=readme-ov-file#database-migration
We have an endpoint that will dump all of your data which you can then load into your own postgres instance.

See info here : https://github.com/getcord/cord-preview?tab=readme-ov-file#database-migration


Added some more devices

Added the following devices

UV Index ("WU - UV straling" in screenshots below)
Visibility ("WU - zicht")
Solor Radiation ("FC - Zonnestraling")
Motion Detector ("Bewegingssensor")
Lux Sensor ("Bewegingssensor Lux")

Used icons from materialdesignicons.com for these devices.
Changed the icons from temp, hum and rain gauge to materialdesignicons.com as well.
Added comments to index.html on the svg's used from materialdesignicons.com.

Wow! You've been busy! Thank you for your work :)

We'll need another major update on the wiki page :) It's getting rather messy, I think I'll try to turn it into a table instead of that long flat list.

Great additions..!

Thanks for updating the wiki @gerard33 !

You're welcome :)


[FEATURE] save settings to the backend

Description
When a user logs out, the settings are gone, which isn't good.
tasks:

[ ] save it to the database
[ ] retrieve it when user logs in (only) and save it in local storage
[ ] Every time the user goes to the settings page, retrieve the saved data from local storage

Screenshots
No response
Additional information
No response
👀 Have you checked if this issue has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Contributing Guidelines?

[X] I have read and understood the rules in the Contributing Guidelines

Are you willing to work on this issue ?
None

Hey @Dun-sin can you assign this to me?

Hey @Dun-sin can you assign this to me?

Definitely, thanks for wanting to contribute, Make sure you follow the rules 👉🏽here👈🏽, else your PR will not be accepted and will be closed. Good Luck

Hey @Dun-sin should I save settings data in User DB Schema?

Hey @Dun-sin should I save settings data in User DB Schema?

Yes


Add a customization point for user-defined types

Hi, I think it would be a cool addition to the library if there was a way to specify a conversion method, from a type to basic_json, which would be called by the lib.
Here a sample code of the behaviour I'm thinking about:
// library code
template <typename UserDefinedType>
struct json_traits;

// user code
template <>
struct json_traits<MyType>
{
  static basic_json convert(MyType const& val)
  {
    return {{"first_row", val.first_row}, {"some_value", 42}};
  }
};

There could also be a conversion method when get is called
auto obj = json::parse(buffer);
auto val = obj["user_defined_type_value"].get<MyType>();

These are just thoughts for now, but that would remove a LOT of boilerplate in my code.
Plus, this would add some compile-time checks (if the struct is not defined for example)
What's your opinion on that?

That would be cool.  I created to_json and from_json functions for a lot of my types, and use to_json/from_json exclusively even for types it already supports.  Making them work automatically out of the box would be even cooler.

This issue is related to #298 and #280.

I have not understood the role of json_traits completely. Shouldn't there be a constructor in the basic_json class for the json_traits template? Would this constructor then be usable for any class that is specialized by json_traits?

It's all static functions, the class is never instantiated.

I still do not understand what to add to the basic_json class.

Maybe something like this:
template<typename T> basic_json(T&& val) :
    basic_json(json_traits<T>::convert(std::forward<T>(val)))
{
    assert_invariant();
}

There might also need to be some enable_if code to keep the current constructors working, or maybe the current constructors become specializations of the json_traits class instead.

Yeah, this is basically what @gnzlbg and @d-frey described in #298

Indeed, looking at taocpp value.hh and traits.hh can help to understand the idea

I started a POC on my fork. (I didn't modify the re2c file, but I will !)

There is an issue with that ctor however...
// not equality-comparable
struct S{};

int main()
{
// this will call operator==(basic_json, basic_json) if json_traits<S> was specialized
// and it will do so for every operator defined for basic_json ...
  S() == S();
}

I'm looking for a way to bypass this, without making the constructor explicit

(json_traits::convert(std::forward(val)))

What is the advantage of json_traits<T>::convert over a simpler json_convert free function that is found via ADL ?

@gnzlbg one thing that comes to mind is the ability to partially specialize the struct
We could imagine a specialization for boost::optional for example

template <typename T>
struct json_traits<boost::optional<T>>
{
   // ...
};

What's wrong with just using overloading?
template <typename T>
auto json_convert(boost::optional<T> const&) -> ... { ... }

(note: json could include these overloads in some separate header, but they would add a dependency on boost::optional).
I find that for most people free functions and overloading are easier to understand than trait classes and partial template specialization. One thing overloading allows is to implement json_convert once for all Optional-like types (given an OptionalLike concept) using enable_if:
template <typename Optional, CONCEPT_REQUIRES_(OptionalLike<Optional>{})>
auto json_convert(Optional const&) -> ... { ... }

(note: since boost/std/...::optional is not directly used here, json could actually add this overload without introducing a dependency on any of these libraries).

Free functions are definitely easier I agree. I'll look into that!

This comment provides a rough idea about how to implement it to make it as easy as possible for users to serialize their own types. In a nutshell it just proposed adding two customization points (to_json/from_json) to the library in the same way that range-v3 does, and then add some default implementations of these for common types (like std::array, pair, tuple, containers, ...).

I remember this paper, I'll read it more closely, thanks for your input!

I have 10+ years of experience with using traits classes in multiple areas. I'd go for a traits class anytime over a free function. Some reasons:

basic_json is a template. Where do you get the template parameters from for the return type if you are using a free function?
Using a traits class allows you to control the conversion between different areas of your code. basic_json<my_traits_1> is different from basic_json<my_traits_2> (as I basically do it in taocpp/json) and hence you can explicitly control how values are converted between the two areas. They don't mix by accident.
You can not "stack" the free functions. With a traits class, you can derive from it and specialize for some types. I used this to specialize the default traits class to overwrite the serialization of a double as our logging system (which uses JSON internally) should be able to log all values, including NaN and +/- infinity. By routing even the basic types through a traits class, the user has more options than with a free function.

One final remark for now: Make sure you declare the traits class with an additional parameter defaulted to void:
template< typename T, typename = void >
struct traits;

That way the user can easily specialize with SFINAE when needed, i.e.,
template<typename E>
struct traits<E, std::enable_if_t<std::is_enum_v<E>>>
{ ... };

Hi, I do not know if I understand correctly, but maybe this main.cpp file will be helpful.
you just declare a MAKE_JSON(name_struct, member1, etc...) inside your struct/class
test_json.zip

Where do you get the template parameters from for the return type if you are using a free function?

Template argument deduction? No need to do anything fancy here:
template<typename T, typename... Args>
void to_json(T const&, basic_json<Args...>& j) {
  ...
}

Using a traits class allows you to control the conversion between different areas of your code. basic_json<my_traits_1> is different from basic_json<my_traits_2> (as I basically do it in taocpp/json) and hence you can explicitly control how values are converted between the two areas. They don't mix by accident.

I agree that this functionality is useful, but it comes with some big costs that we should be aware of:

the types that can be serialized/deserialized to a particular json object are part of the json's object type. Changing this results in an API and ABI breaking change.

if a user adds a new type, it needs to understand partial template specialization, void_t, ... just to be able to use their object with the library.

While the first concern might seem more serious, I actually like this library because it is very ergonomic to use, while giving you the power to do something else if you want to.
I think we could find a solution that let's you do both, by having one of the template parameters of basic_json be a trait that lets you fully control what can be serialized from/to different json object types and how, but at the same time giving it a reasonable default type argument that uses ADL for those cases/programs in which you don't care such that everything "just works".
For example, something like:
template <..., typename <class, class> Serializer = JSONDefaultSerializer> class basic_json { ... }

templace<class /*unused*/, class = void>
struct JSONDefaultSerializer {

  template<typename T, typename JSON>
  void to_json(T const& from, JSON& to) {
    json::to_json(from, to);  // uses ADL
   }
   template<typename JSON, typename T>
   void from_json(JSON const& from, T& to) {
     json::from_json(from, to);
   }
};

That way if you want to write your own "JSONSerializer" trait to have full control you can:
templace<class T>
struct MySerializer<boost::optional<T>> {
  template<typename JSON>
  void to_json(boost::optional<T> const& from, JSON& to) {
    json::to_json(from, to);  // uses ADL
   }
   template<typename JSON>
   void from_json(JSON const& from, boost::optional<T>& to) {
     json::from_json(from, to);
   }
};

They don't mix by accident.

At the cost of having different types for your json objects (and thus different ABI), and at the cost of having to put all your conversions into a single trait class that you pass to the basic_json type. With ADL "everything just works" by default. If I suddenly add new type that has the corresponding free functions I don't have to change anything in any of my basic_json types for it to work with them.
I kind of like this library because it is very ergonomic by default, but still gives you the power to change things as you want, we should find a solution that gives us both.

You can not "stack" the free functions. With a traits class, you can derive from it and specialize for some type

Of course you can:
template<typename JSON>
void float_to_json(float const& f, JSON& to) { ... }

template <typename JSON>
void int_to_json(int const& i, JSON& to) { ... }

template <typename T, typename JSON, CONCEPT_REQUIRES(is_float<T>{} or is_integral<T>{})>
void to_json(T const& t, JSON& to) {
  // c++17: selects the best overload
  std::overload(float_to_json, int_to_json)(t, to);
}

I mean you could also use sfinae or tagdispatching, but doing this in C++17 with std::overload (or std::first_overload is trivial).
Anyhow I agree that having a robust way of allowing multiple, different, serializations, of a particular type, to a basic_json object, in the same program (even if its header only) is something worth pursuing. I just don't want to complicate things more than necessary for users that do not need this, and I think it is possible to do so.

I also would wish that the "Serializer" type that is passed to the basic_json object would be a concrete type and not a higher-kinded one. So that users cannot specialize (but still could reuse or inherit from) the default serializer. Doing what @d-frey wants should still be possible:
template <..., typename Serializer = JSONDefaultSerializer>
class basic_json { ... }

struct MySerializer;

using my_json = basic_json<..., MySerializer>;

struct MySerializer {
  template<typename T>
  void to_json(T const& t, my_json& o) {
    my_trait<T>::convert(t, o);  // your trait class would need to be extra
  }
  // from_json is analogous
};

Hi, I've committed a first version with a json_traits struct. I added a constructor, a get_impl overload, and a unit-constructors3.cpp file in the test suite.
I tried to implement the customization-point design proposed by Eric Niebler, unfortunately variable templates are not supported in VS 2015, so I decided to begin with the traits struct.
I'm sure I missed quite a lot of things, so I'm looking for your feedbacks.

Range-v3 implementation does not require variable templates (see
include/range/v3/utility/static_const.hpp).
On Monday, 17 October 2016, Théo DELRIEU<EMAIL_ADDRESS>wrote:

Hi, I've committed a first version
https://github.com/theodelrieu/json/commit/a2a8fec577eff7392f124570f3286d6a2e30f0b6
with a json_traits struct. I added a constructor, a get_impl overload,
and a unit-constructors3.cpp file in the test suite.
I tried to implement the customization-point design proposed by Eric
Niebler, unfortunately variable templates are not supported in VS 2015, so
I decided to begin with the traits struct.
I'm sure I missed quite a lot of things, so I'm looking for your feedbacks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nlohmann/json/issues/328#issuecomment-254174615, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA3Nppi9q2mgW4UExUy_4l8Q_HnYCbBrks5q01I_gaJpZM4KU7Jf
.

I see, I tried to use the example code from the paper, but the code you linked compiles on VS2015. I will try to implement that too

Hi, I've implemented the from_json/to_json free function support on my fork.
I'd really appreciate all your feedbacks on the diff I linked. (especially you @gnzlbg, since you're more aware than me about the subject of ADL free-function style!).
I wrote comments questioning the design choices I've made in json.hpp.
I also added some stuff that might be out of this feature's scope, that I should add in a different PR (e.g. alias templates)

I think it is easier to give feedback if you open a PR, just make it clear to @nlohmann that the work is not finished yet and that it should not be merged yet.

Some things:

you probably don't want to use remove_cv/remove_reference<T> independently from each other, but rather always use remove_cv<remove_reference<T>>. This is typically called uncvref_t, e.g., see range-v3.

design: you do a lot of "if has json_traits do this, else if from_json/to_json are valid overloads, do that. I think this is too complicated. In my opinion it is easier if:

JSONSerialization is a template parameter of basic_json
you create a json_serialization_adl "trait", that has from/to static members that call from_/to_json free functions via ADL.
you use that as the default template argument for the JSONSerialization template parameter.

That is, to serialize something in basic_json you only use JSONSerialization::from/to and be done with it.
If the user doesn't care, ADL will trigger and do "the easy thing".
If the user does care like @d-frey they can write their own trait class that does whatever they want and pass it as a template parameter to, e.g., have different basic_json types that serialize the same objects to and from json in different ways.

I opened a PR.
At first I found the template-argument design a bit annoying to people specializing the traits struct.
But it avoids some confusion, and lets people control serialization. I'll implement that and come back to you, thanks for the feedback!

@theodelrieu Instead of std::remove_cv_t<std::remove_reference_t<...>> you probably want to use std::decay_t<...>. It does what remove_cv+remove_reference does and more, like taking care of turning const char(&)[N] into const char* - what is what you most likely want. It's almost as if it was made for this kind of use-case... ;)

like taking care of turning const char(&)[N] into const char* - which is what you most likely want.

As @d-frey  says, std::decay_t "decays"  types like when passed by value to functions arguments (which does array to pointer conversion). However, where @theodelrieu uses remove_cv<remove_reference<T>> he actually doesn't want the arguments to decay like as when passed to functions because that would break both ADL and the trait system for serialization.
An user (or probably, this library) can  implement to_/from_json for C-arrays using ADL:
template <typename T, std::size_t N, typename JSON>
void to_json(T[N] const&, JSON&);

or by specializing a trait class:
template<typename T, std::size_t N>
struct json_traits<T[N]> { ... };`

But if you "decay" the types before using ADL or the trait class, the following will be try to be picked instead (and will fail to pattern-match):
template <typename T, typename JSON>
void to_json(T*, JSON&);

template<typename T>
struct json_traits<T*> { ... };`

So what @theodelrieu actually wants is typically called uncvref_t:
template <typename T>
using uncvref_t = std::remove_cv_t<std::remove_reference_t<T>>;

Sadly, this is not in the standard library yet, but while std::decay_t almost does what you want, it breaks in subtle ways. The only safe situation in which one should really use std::decay_t is when one actually really wants to perform decaying of values as when passed to functions as arguments, which basically means if you are implementing something like std::bind/std::mem_fn/std::result_of/std::invoke/... and such. For picking specializations in trait classes, uncvref_t is what always works.

This feature is implemented, see #435.


Transformation Widget: Translation

The little wiry helper object we know from just about any game engine. The Widget. Let's have one!
The widget lets us move a cube around space easily just by clicking and dragging. See the attached image to see what the widget ought to look like.
For this milestone, we expect:
-Widget appears when object is highlighted (see the Game Objects Framework Issue)
-There are 6 parts to the widget: one for each axis and one for each combination of two axes.
-X is red(#ff5c5c); Y is green (#68ff5c) and Z is blue (#0090ff). The combinations are dark blue (#112d43).
-Clicking on any part of the widget highlights that part and enables "move the thing" mode
-The highlighted widget part becomes 30% darker when the mouse is hovering over, and yellow when mouse button is down (#dcef60)
-Dragging the mouse causes the object to follow the cursor - locked to the appropriate axis/axes
-While dragging the widget, if the mouse goes to the extreme of the window, warp it to the other side so we may continue to drag the object in the same direction to our heart's content. (Unity does this and it's great)

Although Pull Request #36 has a translation gizmo, I think more support from the other issues will need to be added before we flesh this out.
I'd like to finish #29 which might depend on #17 which might depend on #22...
Much work to be done!

Closing for now as part of a revamp of our github issues. Larger scale tasks like this will be tracked in Trello


Multiple certificate stores

Do you want to request a feature or report a bug?
Feature
What did you expect to see?
The goal of this proposal is to be able to have multiple certificate store in Traefik.
Add dynamic certs in a store
When you add dynamic certificates in a file provider, you can indicate in which store you want to include this certitificate.
[[tls]]
  [tls.certificate]
     stores = ["store1", "store2"]
     certFile = "fixtures/https/snitest.com.cert"
     keyFile = "fixtures/https/snitest.com.key"

[[tls]]
  [tls.certificate]
     stores = ["store2", "store3"]
     certFile = "fixtures/https/snitest.org.cert"
     keyFile = "fixtures/https/snitest.org.key"

Use a specific store in TLS
When you enable TLS on a router you can choose which store you want to use for the TLS Termination (example in toml but we will able to specify in all the provider)
[http.routers.router1]
 Service = "service1"
 Rule = "Host(`snitest.com`)"
 [http.routers.router1.tls]
 store="store1"

[http.routers.router2]
 Service = "service2"
 Rule = "Host(`snitest.org`)"
 [http.routers.router2.tls]
 store="store3"

ACME / Store
When configuring ACME you will able to configure in which store we want to store our generated certificates.
--acme.store="my-acme-store"

Default value
When you don't specify any store ( in the three previous case ), we will automatically use a store named default
TLS Store options
In the dynamic conf, in a file (using the file provider), you can define some StoreOption like this:
   [tlsStores.default.DefaultCertificate]
   certFile = "fixtures/https/snitest.com.cert"
   keyFile = "fixtures/https/snitest.com.key"

   [tlsStores.store1.DefaultCertificate]
   certFile = "fixtures/https/snitest.com.cert"
   keyFile = "fixtures/https/snitest.com.key"

Currently you can set stores for TLS certificates, but I don't see how you can actually use them. Guessing this is the feature request for such issue?

Any info? That would be extremely useful

I absolutely needed a way to add multiple cert/key while simultaneously use let's encrypt.
So, I quickly hack the following: https://github.com/robotinfra/traefik-patch-acme
it combine one or multiple secrets, each with their key/cert pair and modify the persistent file used by traefik to store TLS files (acme.json). Used as a initContainer it "patch" the store at startup.
It will solve my own needs until this issue is fixed. anybody feel free to use as well

Hey,
So you want to use 2 or more internally signed certificates? and use
LetsEncrypt at the same time?
--
FingerlessGloves
On Wed, 7 Oct 2020 at 09:11, Bruno Clermont<EMAIL_ADDRESS>wrote:

I absolutely needed a way to add multiple cert/key while simultaneously
use let's encrypt.
So, I quickly hack the following:
https://github.com/robotinfra/traefik-patch-acme
it combine one or multiple secrets, each with their key/cert pair and
modify the persistent file used by traefik to store TLS files (acme.json).
Used as a initContainer it "patch" the store at startup.
It will solve my own needs until this issue is fixed. anybody feel free to
use as well
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/traefik/traefik/issues/4756#issuecomment-704771216,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA2VNXYR733SI2IZGC7PUDTSJQPEBANCNFSM4HFNXIQQ
.

Hello,
I need this too. Why do you have made a different behavior for KubernetesCRD ?

@jbdoumenjou redirect me. if you look at #8090 and #8211 we have a problem in service discoveries (Kubernetes in this example) with a single TLS Store. Multiple TLS store may be a thing, one per namespace on Kubernetes, maybe, i don't know how traefik will handle incoming TLS records. I think the best is to change TLS matching when in Kubernetes service discovery to find for which Ingress it was and find the bound certificate. This will lead to a bit more latency on new TLS negociation but it will be at least the good one

Would love to see this get added to the 3.0 roadmap.  We're running into an issue where we have a multi-tenant cluster where every app brings their own TLS certs (trust me, I'd rather be doing ACME, but "compliance").
As of 2.9, we're able to define the default "TLSStore" as a resource as something like:
apiVersion: traefik.containo.us/v1alpha1
kind: TLSStore
metadata:
  name: default
  namespace: traefik-ingress
spec:
  certificates:
    - secretName: app-a-tls
    - secretName: app-b-tls
  defaultCertificate:
    secretName: default-tls-certs

While this is better now that it supports the spec.certificates[] directive, it still means that when we deploy a new app, its a non-atomic operation.  We have to know about all kubernetes tls secrets when we update (or get creative with a PATCH api call).  Would be much cleaner if we could just define a per-app TLS store and reference it in that apps IngressRoute.  Just food for thought

Stupid question, but why isn't the cert store resolver-scoped? Is there a scenario where different providers would effectively store the same issued certificate? My case is (obviously / luckily) LE + acme, but in other scenarios I would expect certificates to come from their respective resolver-store.

My current workaround to force the LE staging -> production switch is to change the staging certificate storage file.
Example, before:
certificatesResolvers:
#...
  staging:
    acme:
      tlsChallenge: true
      storage: "/letsencrypt/staging-v1.json"
      caServer: "https://acme-staging-v02.api.letsencrypt.org/directory"

after:
certificatesResolvers:
#...
  staging:
    acme:
      tlsChallenge: true
      storage: "/letsencrypt/staging-v2.json"
      caServer: "https://acme-staging-v02.api.letsencrypt.org/directory"

This avoids the need to edit the file manually and remove the concerned section.
Would be happy to know a simpler workaround though.

After spending 15 min troubleshooting the cert resolver, I remembered about this issue and sure enough, I got bitten by it again.
The workaround mentioned above did not seem to work for me. I am testing this on the Traefik v3.0 beta release.
With two separate files for LE staging and production certificates, switching the cert resolver in my dynamic config did not result in new certificates being loaded.
# static config
providers:
  file:
    directory: /etc/traefik/file_provider

certificatesResolvers:
  letsencrypt_staging:
    acme:
      storage: /etc/traefik/acme/acme_staging.json
  letsencrypt_prod:
    acme:
      storage: /etc/traefik/acme/acme.json
    # ...

The issue of course is with the single cert store in Traefik mentioned above.
Is this something the Traefik team / maintainers would like to see added? Given a nudge in the right direciton, I would love to contribute to this feature.

Hello @jerrywoo96,
Thank you for reaching out.
Today it's not possible to have several certificate stores. This PR is here to track this need.

Hi, I need to set a specific tls certificate for one of my routers, is it actually possible to do it without the stores being implemented yet?

Hello,
I would love to see this get implemented. Here is my use case.
Application A: sub.toto.com not behind cloudflare proxy so using cert resolver to automate cert
Apps B and C behind cloudflare proxy at sub1 and sub2 .toto.com. The origin cert is a wildcard. If I upload it, it will always be served for apps A,B, and C. Therefore app A will get an insecure cert.

I am surprised that this request hasn't been resolved in 5 years.
This is a very important feature. It’s quite strange that all certificates live in a single namespace, and I cannot specify a particular certificate for my router.
For example, I have a Let's Encrypt certificate for *.traefik.me, and there is an API for legacy devices for which I purchase a separate certificate, also with *.traefik.me.
However, I cannot specify the desired certificate because the first one in the list will always be used, which is Let's Encrypt. If I make Let's Encrypt the default, then the purchased certificate is used for everything, but this can lead to issues, for example, if the renewal is delayed.
Is there any hope for improvement in this regard?
---
http:
  routers:
    mysite.traefik.me:
      rule: Host(`mysite.traefik.me`)
      service: api@internal
      entryPoints:
      - web
    mysite.traefik.me-tls:
      rule: Host(`mysite.traefik.me`)
      service: api@internal
      entryPoints:
      - websecure
      tls: {}
    stb-old-device.traefik.me:
      rule: Host(`stb-old-device.traefik.me`)
      service: api@internal
      entryPoints:
      - web
    stb-old-device.traefik.me-tls:
      rule: Host(`stb-old-device.traefik.me`)
      service: api@internal
      entryPoints:
      - websecure
      tls: {}
tls:
  certificates:
  # self sign end expired *.traefik.me
  - certFile: |-
      -----BEGIN CERTIFICATE-----
      -----END CERTIFICATE-----

    keyFile: |-
      -----BEGIN PRIVATE KEY-----
      -----END PRIVATE KEY-----

  # real *.traefik.me
  - certFile: |-
      -----BEGIN CERTIFICATE-----
      -----END CERTIFICATE-----

    keyFile: |-
      -----BEGIN PRIVATE KEY-----
      -----END PRIVATE KEY-----

  # self sign end expired mysite.traefik.me
  - certFile: |-
      -----BEGIN CERTIFICATE-----
      -----END CERTIFICATE-----

    keyFile: |-
      -----BEGIN PRIVATE KEY-----
      -----END PRIVATE KEY-----

In the example above, for stb-old-device.traefik.me, an expired self-signed *.traefik.me certificate will always be chosen, even though a valid *.traefik.me certificate exists lower in the list. However, there is simply no way to specify the desired one.

Let's say we have two zones:

*.domain.com
*.a.domain.com

and two certificates: one from Let's Encrypt and another from DigiCert.
For the second zone, we want to use the DigiCert certificate—for example, for old devices or testing, as Let's Encrypt doesn't work there.
Let's Encrypt has the following description:
X509v3 Subject Alternative Name
   DNS:*.a.domain.com, DNS:*.domain.com, DNS:domain.com

DigiCert has this description:
X509v3 Subject Alternative Name
   DNS:*.a.domain.com

If we add Let's Encrypt as the first certificate in the list, DigiCert will never be used because both satisfy the *.a.domain.com mask, and the first one in the list will always be chosen.


Easey Scheduler Code QL Uncontrolled format string

Private Zenhub Image

Based on discussion during refinement on 11/14 will work on this issue if the team has capacity to fix it.

This is a bug that is coming from the User Interface of SilkierQuartz. Ideally, only admins will have access to the UI. Since this is a denial of service flag, and only admins can take advantage of the issue, it makes sense to close this bug. Fixing this issue would require a deep understanding of the SilkierQuartz UI logic. At some point the Quartz UI security will need to be analyzed. It does not appear to be secure from my base analysis.

This needs research and not a priority, putting this back in the backlog.


Android: Background notification is not shown until foreground notification has been shown atleast once

Background notifications are not working when I,
1: initialize the app
2: add an FCM token
3: close the app.
But when I keep the app in the foreground, receive a foreground notification, and close the app, background notifications start working.

https://stackoverflow.com/help/how-to-ask
https://stackoverflow.com/help/mcve
Not enough details to help, sorry

index.js
/**
 * @format
 */

import {AppRegistry} from 'react-native';
import {initNotifee} from 'utils/notifee';
import App from './App';
import {name as appName} from './app.json';

initNotifee();

AppRegistry.registerComponent(appName, () => App);

notifee.js
const onMessageReceived = async message => {
  // Do something
  if (message?.data?.notifee) {
    const notification_data = JSON.parse(message.data.notifee);
    notifee.displayNotification({
      ...notification_data,
      android: {
        ...notification_data.android,
        smallIcon: 'ic_notification',
      },
    });
  }
};

export const initNotifee = async () => {
  try {
    // register fcm listener
    messaging().onMessage(onMessageReceived);
    messaging().setBackgroundMessageHandler(onMessageReceived);

    // create/update channel
    notifee.createChannel({
      id: 'alerts',
      name: 'Alerts',
      lights: true,
      vibration: true,
      vibrationPattern: [200, 100, 200, 100],
      importance: AndroidImportance.HIGH,
    });
  } catch (err) {
    return false;
  }
  return true;
};

and here is how my notification object looks:
{"notifee": {"android": {"channelId": "alerts"}, "title": "hello"}}
Now, when I open the app, notifee is initialised in index.js file. And when the user logs in, fcm token is registered like this:
export const updateFCMToken = async () => {
  // Register the device with FCM
  await messaging().registerDeviceForRemoteMessages();

  // Get the token
  const token = await messaging().getToken();

  const response = await ApiAxios({
    method: 'post',
    url: BASE_API_URL,
    data: {
      query:
        'mutation updateFCMToken($token: String!){fcmToken(token: $token){token}}',
      variables: {token: token},
    },
  });
  if (response.data?.errors?.length) {
    throw Error('response contains errors');
  }
};

I've checked the backend and the token is being updated successfully. The issue arises when I send background notification before sending foreground notification. Sending the background notification is not shown by notifee.
But background notifications starts working fine after I've sent at least 1 foreground notification.

const initialNotification = await notifee.getInitialNotification(); use this for trigger event in android

Still not working

I just scanned this, and in notifee.js you are referencing symbols that were never imported. I suspect that code is not actually complete (https://stackoverflow.com/help/mcve) so I hesitate to spend much time looking at it

I was able to fix this by setting priority to high in FCM configuration on the backend when sending messages. This link: https://rnfirebase.io/messaging/usage#data-only-messages explains the issue I was facing.

Background notifications are not working when I, 1: initialize the app 2: add an FCM token 3: close the app.
But when I keep the app in the foreground, receive a foreground notification, and close the app, background notifications start working.

Experiencing the same @doolb14


Test libssl doesn't move buffers in async IO

That guarantee doesn't currently exist, but some clients could benefit
from it.
Related to #12631
No idea if this is small enough for a "CLA: trivial". I don't expect it to be merged as it is. But creating it to start the conversation.
I have seen https://www.openssl.org/policies/codingstyle.html. But, there is any clang-format/indent file I can use to automate the process?

This PR has the label 'hold: cla required' and is stale: it has not been updated in 30 days. Note that this PR may be automatically closed in the future if no CLA is provided.  For CLA help see https://www.openssl.org/policies/cla.html

This PR has the label 'hold: cla required' and is stale: it has not been updated in 30 days. Note that this PR may be automatically closed in the future if no CLA is provided.  For CLA help see https://www.openssl.org/policies/cla.html

This PR has the label 'hold: cla required' and is stale: it has not been updated in 61 days. Note that this PR may be automatically closed in the future if no CLA is provided.  For CLA help see https://www.openssl.org/policies/cla.html

This PR has the label 'hold: cla required' and is stale: it has not been updated in 92 days. Note that this PR may be automatically closed in the future if no CLA is provided.  For CLA help see https://www.openssl.org/policies/cla.html

This PR has the label 'hold: cla required' and is stale: it has not been updated in 123 days. Note that this PR may be automatically closed in the future if no CLA is provided.  For CLA help see https://www.openssl.org/policies/cla.html

This PR has the label 'hold: cla required' and is stale: it has not been updated in 123 days. Note that this PR may be automatically closed in the future if no CLA is provided.  For CLA help see https://www.openssl.org/policies/cla.html

This PR has the label 'hold: cla required' and is stale: it has not been updated in 154 days. Note that this PR may be automatically closed in the future if no CLA is provided.  For CLA help see https://www.openssl.org/policies/cla.html

This PR has the label 'hold: cla required' and is stale: it has not been updated in 185 days. Note that this PR may be automatically closed in the future if no CLA is provided.  For CLA help see https://www.openssl.org/policies/cla.html

This PR has the label 'hold: cla required' and is stale: it has not been updated in 216 days. Note that this PR may be automatically closed in the future if no CLA is provided.  For CLA help see https://www.openssl.org/policies/cla.html


[Feature Request] Add addons from a profile without replacing the current addons.

If you have addons A, B, C loaded and you choose PROFILE_TWO with D, E, F then A, B, C addons are disabled and D,E,F are enabled. My suggestion is to have an option to add PROFILE_TWO's addons D,E,F to A,B,C

Duplicate of #26


Feat/span and style

Well, this will teach me.
I suppose it may take me more than one step or try at this to get things back the way the were. Lesson learned.

Closing this PR, because I now I think I know how to get GitHub to re-open the original one with all our conversation.


Remove anything related to obsolete frames mode

This is a proper fix for #599. Synopsis would only show if it is
contained in a .no-frame block which is a remain prior #514.
Also removes some obsolete javascript for searching a haddock page(?).

@ndmitchell I saw you were adding the search stuff about 10 years ago in https://github.com/haskell/haddock/commit/12b1c76fefc78b2a0fa54138a550c73802b1847d.  Is this safe to remove without breaking 3rd party tooling?

@alexbiehl if it's not referenced internally it's probably dead code.


feat: concurrent file chunk uploads

Proposed changes
Perform concurrent file chunk uploads!
In the current implementation of the SDK, the files and chunks are uploaded one after another, which is not a really good approach and has a really big impact in the upload speed (it was easy to implement though 😅). This PR introduces concurrent upload for chunks, which should improve upload speeds specially for big files. Files are still uploaded in serial, on step at a time!
The process works as follows now:

The uploadFile function creates an array of chunks with all the necessary information to perform the upload. That includes the transfer or board is, file multipart info, the Blob chunk, and the upload URL.
These chunks are pushed to a queue with a concurrency of 5 by default (can be configured). The queue has an async worker assigned called uploadChunk that is responsible to perform the upload and notify the chunk when it is completed.
When a chunk is pushed to the queue, a callback can be assigned that gets notified when the upload succeed or failed. If it failed, we add the chunk again to the queue, if the number of retries didn't reach the limit. If the upload is successful, we notify the file and check if the complete file has been uploaded.

Types of changes

[ ] Docs (missing or updated docs)
[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Improvement / maintenance (removing technical debt, performance, tooling, etc...)

Checklist

[x] I have read the CONTRIBUTING doc
[ ] I have added necessary documentation (if appropriate)
[x] Code changes are covered by unit tests.
[ ] Any dependent changes have been merged and published in downstream modules

@seelts @spirosikmd I refactored the way the chunk upload URL is created. I understand the way it was done was confusing, and I wrote it in a more understandable way (I hope). Now, the chunks holds all the information necessary to retrieve the URL (transfer or board id, multipart id, part number) and the upload URL is fetch calling the function just before the upload.
https://github.com/WeTransfer/wt-js-sdk/pull/202/commits/2462107f47d8731ae18df93feb8ec34e40d222d9#diff-5fe63dc0ff63a6896dd5624dd1b08fed
https://github.com/WeTransfer/wt-js-sdk/pull/202/commits/2462107f47d8731ae18df93feb8ec34e40d222d9#diff-fd63b30db6a127b4b96c1892aa2ba81d

:tada: This PR is included in version 1.2.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[Fix-8119][API] Update ProcessInstance error without reason output

Purpose of the pull request
This pr will close #8119

Codecov Report

Merging #8122 (c832ab5) into dev (e7f480b) will decrease coverage by 0.08%.
The diff coverage is 0.00%.

:exclamation: Current head c832ab5 differs from pull request most recent head 6172a30. Consider uploading reports for the commit 6172a30 to get more accurate results

@@             Coverage Diff              @@
##                dev    #8122      +/-   ##
============================================
- Coverage     41.47%   41.38%   -0.09%
+ Complexity     3738     3730       -8
============================================
  Files           637      637
  Lines         27141    27142       +1
  Branches       3089     3089
============================================
- Hits          11257    11233      -24
- Misses        14801    14825      +24
- Partials       1083     1084       +1

Impacted Files
Coverage Δ

...api/service/impl/ProcessDefinitionServiceImpl.java
31.98% <0.00%> (-0.03%)
:arrow_down:

...er/master/processor/queue/TaskResponseService.java
50.00% <0.00%> (-18.19%)
:arrow_down:

...rver/master/processor/queue/TaskResponseEvent.java
93.54% <0.00%> (-6.46%)
:arrow_down:

...e/dolphinscheduler/remote/NettyRemotingClient.java
50.70% <0.00%> (-2.82%)
:arrow_down:

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 e7f480b...6172a30. Read the comment docs.


Process started with --test not killed

I'm trying to use --test Devel.main to automatically restart a webserver. On first runs this works, but on subsequent runs starting the webserver often fails because of a port conflict. It turns out the previously started webserver process is still around, and it sticks around even after killing ghcid.
Searching a bit for old issues I find some related to this problem. I'm using ghcid version 0.7 so I believe I should be have all existing patches.
Our current build script is based on yesod-devel. It includes the following 'hack':
From yesod-bin:

Unfortunately, directly killing the ghc interpreter has never worked reliably, so we have an extra hack: when killing the process, yesod devel also writes to a file yesod-devel/devel-terminate. Your devel script should respect this file and shutdown whenever it exists.

I'm not too familiar with the internals of ghcid so this may be way off base, but could the problem yesod-devel circumvents here be the same plaguing ghcid?

Turns out the server I was running wasn't shutting down because of a bug in network: the server web server upon receiving a sigint signal got stuck closing its websocket. Upgrading network fixed my issue.
I'll close this now. Sorry for the noise!

Great, thanks for the update!

I running into the same problem. Have a servant server which is forked from the main thread, and it isn't killed on file change. Tested without forking, i.e. running directly from the main thread. The same. Ports and file handles are not released.
Running with
ghcid -W -c 'stack ghci server:exe:server-bin' -T 'Main.main'
Instead of Yesod's approach which requires changing/adding some code, a simpler way might be to have an arg to ghcid, like (bikeshedding)
--run-after-kill-and-before-reload=my-killer.sh
could do the trick?
Does this seem feasible and easy?
We could put any command in my-killer.sh which would kill the process(es), wait longer if required, or even do some prep for starting, cleanup, etc.

Something like (I just glanced the code, so maybe another place)
sessionReload :: Session -> IO ([Load], [FilePath])
sessionReload<EMAIL_ADDRESS>= do
    -- kill anything async, set stuck if you didn't succeed
    old <- modifyVar running $ \b -> return (False, b)

    -- if killerPath is specified (Just), run it, regardless of `stuck`
    void $ createProcess . shell <$> getKillerPathSomehow session

    stuck <- if not old then return False else do
        Just ghci <- readIORef ghci
        fmap isNothing $ timeout 5 $ interrupt ghci

    if stuck then sessionRestart session else do
      ...

I was using stack and forgot this is ghci, there's no bin filename to kill from outside, so code change needed in app. :-(
I did a little bit of testing this idea and it seems to work if the code is in sessionReload. kill doesn't get fired for some reason.
sessionReload :: Session -> IO ([Load], [FilePath])
sessionReload<EMAIL_ADDRESS>= do
    let killerScript = Just "ghcid-killer-script" -- hardcoded, need access to `Options`
    maybe (pure ())
          (\ks -> do
             (_,_,_,p) <- createProcess $ shell ks
             void $ waitForProcess p              -- wait for shell process to finish
          )
          killerScript
    ...

Luckily, I already have the shutdown endpoint in my app, so the only thing needed was the ghcid-killer-script:
# ghcid-killer-script
curl localhost:3003/admin/stop

Any remarks/suggestions on the approach?

If anybody wants to test, here it is.

@ndmitchell Any thoughts?

@vlatkoB sorry for the delay in coming back to you.
If you really need such a killer script happy to take a command line flag for something to run and cleanup at some point. However...

Why not run this cleanup script at the start of the test? The test is a GHCi command, so :!run-killer is a perfectly legitimate command. If you do it at the start that seems simpler, and also speeds up the reload cycle and time to errors.
ghcid deliberately send Ctrl-C to the test program. If you are responding and handling Ctrl-C properly it should do the right shutdown. Fixing that might be useful regardless.

No problem, not an urgent issue, this one. :-)
I do not really need such a script, but tried to solve an issue, and came up with some kind of solution.
I'm actually trying to use ghcid as yesod devel, so it is not a one-time test, but a Servant server (i.e. a never-ending process).

It responds to Ctrl-C from shell (both stack run server-bin and ghcid ...), but not from inside the ghcid. Port and file handles are still left open, and after a rebuild/reload, server "starts", but with port already in use message.
As observed in system-monitor, after Ctrl-C from shell server need ~2-3 secs to disappear from pid list, so that might be the culprit. Although, I tested local ghcid that has timeout 15 and yet the same.

I'm not using ghci much, so can you give me a full command line example to test? Maybe I'm not starting ghcid correctly. What I tried still results in port already in use and/or resource busy (file is locked)message. Like the new server is started before the old one has the time to shutdown.

This is what I'm using.
Ghcid (with no script): ghcid -W -c 'stack ghci server' -r or -T 'Main.main'
Script (run-killer):
echo "Killing localhost"
curl -s localhost:3003/admin/stop
sleep 4

I imagine you writing:
ghcid -W -c 'stack ghci server' -r or -T ':!script-killer' -T 'Main.main'

Which will cause the "test" operation to first call script killer, then main to start it up again.

It doesn't work. Seems those -T are performed differently than from the shell. If I curl localhost:3003/admin/stop from the shell, the server stops, ghcid displays a message, change the code, recompiles and all good. But when the kill script is invoked with -T, it doesn't stop. I can curl localhost:3003/hello and it works, but for stop getting 408.

I'm using emacs, and since killing from outside works, solved it with before-save-hook. If anybody needs it, here it is:
;; Run 'stop-server' located in project's root on every manual save of Haskell file
(defvar stop-server-script-name "stop-server"
  "Name of the script in project root directory." )
(defun stop-dev-server ()
  "Kill server so ghcid can reload with server already stopped from outside."
  (when (eq major-mode 'haskell-mode)                                     ;; if haskell mode
    (when (memq this-command '(save-buffer))                              ;; if manual save
      (let* ((project-root (projectile-project-root))                     ;; curr project root
             (script-path  (concat project-root stop-server-script-name)) ;; full path
             (script-exist (file-exists-p script-path))                   ;; does it exist
             (shell-cmd    (concat script-path " %s")))                   ;; make it accept param
        (if script-exist
            (progn (message "Stopping server with script: %s" script-path)
                   (shell-command-to-string (format shell-cmd buffer-file-name)))
          (message "Missing script %s. No action." script-path))))))
(add-hook 'before-save-hook 'stop-dev-server)

I'll try to dig into this issue when I get more free time.

No idea why -T doesn't work... That is odd. If you can figure that out I'd be keen to fix it.

I remember that, while I was searching/testing for the most appropriate place for the new code, the new code didn't work inside the kill function (regardless of secs amount for timeout), and some other places, only inside the sessionReload (and here the new code must be the first to execute, before modifyVar running).
Is there some parallelism going on in/before kill? Although the new code waits for the script to finish, other things do not wait for it, so some code might get executed partially.

@vlatkoB very odd... I don't understand at all.

I was in a bit of a hurry to make it done, so I might have missed something. Will test again with a very small/basic Servant app, maybe it's something in the app I used it with.

I noticed something that might be related to this issue.
When I start ghcid session from script
#!/bin/bash

## script for starting named ghcid session
CMD="ghcid -W -c \"stack ghci server\" -T \":main -c config/config-300$1.yaml\""
setsid bash -c "exec -a "GHCID-RUN" $CMD"

get processes info
$ ps -o pid,ppid,sess,cmd -U vlatko | grep -v "color" | grep 19861
PID   Parent Group CMD
19909 19908  19861 GHCID-RUN -W -c stack ghci server -T :main -c config/config-3005.yaml
19914 19909  19861 .stack/programs/x86_64-linux/ghc-tinfo6-8.6.4/lib/ghc-8.6.4/bin/ghc ....

and try to kill them with pkill -9 -g 19861 (or kill -9 -- -19861, or kill -TERM 19861, or any other weapon I could find :-) ), ghc survives (PID is the same, it is not restarted).
$ ps -o pid,ppid,sess,cmd -U vlatko | grep -v "color" | grep 19861
PID   Parent Group CMD
19914 19909  19861 .stack/programs/x86_64-linux/ghc-tinfo6-8.6.4/lib/ghc-8.6.4/bin/ghc ....

I'm noticing the same thing with Flora these past days. This is the first time I'm encountering this and I'm quite lost as to why it didn't happen before.
I'm don't think I'm particularly stressing ghcid on this one, my command-line is ghcid --target=flora-server --restart="src" --test 'FloraWeb.Server.runFlora'.
I'm running Fedora 34.

When using nix shebangs the following works for me to overcome the issue (assuming the executable source file is ./Main.hs):
#! /usr/bin/env nix-shell
#! nix-shell -p ghcid
#! nix-shell -p "haskellPackages.ghcWithPackages (p: with p; [net-mqtt])"
#! nix-shell -i "ghcid -c 'ghci -Wall' -T':!pkill --full ghc\\ .\\*./Main.hs' -T main"

I'm a Windows user, so don't know what is going on here. If anyone can shed some light, then we can investigate. Reopening for now though, as it does seem there is some issue underlying it.

Update: turns out an infinite loops from a websocket endpoint was somehow triggering a sequence of events that was leading to this.

The -T:!script-killer trick does not feel convenient. Because for different apps different killer scripts are needed (or a general ghcid children processes killer, that's awkward too).
It seems ghcid can know the process id of the spawned process, but not sure. If so, I think ghcid can be supplied with an option to automatically kill the process and its children on reload.

I'm not sure that pkill will help at all here, since it's all happening part of the same process.
ghcid detects that a change to a module has happened, loads the new modules and calls the new test.

My current theory is that https://github.com/ndmitchell/ghcid/blob/master/src/Session.hs#L207 which is supposed to SIGINT doesn't succeed but exits cleanly.

I made a reproducer here: https://github.com/domenkozar/ghcid-reload-repro
Basically I see this bug happens under two conditions:

the code doesn't respond to ctrl-c, usually because it's too busy looping or you got the handlers wrong (catching exceptions). If it's looking you can try passing -fno-emit-yields as a ghc-options.
ghcid reloader doesn't reload any forked threads! my reproducer demonstrates the issue

@ndmitchell if reloading isn't possible by tracking the threads, can we force ghcid to always restart?

@ndmitchell could we run GHC.Conc.listThreads >>= mapM_ GHC.Conc.killThread upon reloading ghci?

Noting that I also ran into this with a GUI application yesterday.


create_vm failure

Guys
Could someone please help me debug this issue? I keep getting this error on attempt to deploy VMs.
L Error: Unknown CPI error 'Unknown' with message 'Could not transfer file 'https://<IP_ADDRESS>/folder/vm-c8fa7d28-67ea-4538-a067-c3c137cd76f7/env.json?dcPath=ppc&dsName=vol-NFScf4', received status code '500'' in 'create_vm' CPI method
Task 162 | 16:42:55 | Creating missing vms: access_z1/02480489-74d1-4605-b53f-41e8e4c8da3c (0) (00:06:32)
Task 162 | 16:42:55 | Error: Unknown CPI error 'Unknown' with message 'Could not transfer file 'https://<IP_ADDRESS>/folder/vm-c8fa7d28-67ea-4538-a067-c3c137cd76f7/env.json?dcPath=ppc&dsName=vol-NFScf4', received status code '500'' in 'create_vm' CPI method

This likely means that vcenter is facing some internal error. CPI cannot do anything other than retrying it before giving up. It already does retry 5 times.

@alakshman  - If you are not facing this issue anymore, would you mind if I close this issue?

Yes please close it.


edittext.setError shows "null,errormessage"

I am working on Android IceCream. I noticed that edittext.setError shows "null,errormessage".
Am I doing something wrong here?
Here's the code.
 if (commentEditText.getText().toString().isEmpty())
                    commentEditText.setError("Please Write a Comment");

Seem like your EditTest has et_supportMode attribute set to helperWithError . You should change it to helper

Got it! Will check! Thanks!


std.stdio is not parsing correctly

The title pretty much says it all. After the first else version statement The Psi seems to disintegrate into a list of tokens, instead of a syntax tree.

you have skype? or another messenger we can have a quick chat on?

Uh can't do video chat, but I can use gitter/hangouts/telegram

gitter is good

I don't really know where to put this comment, so I'll put it here. In order to improve the parser it could be a good idea to make use of the "private" keyword more. It would greatly simplify the psi tree, potentially making it easier to debug problems

Yeah definitely - it was on my list - I'm still not sure though how it could look and what is needed to implement the other features like goto and refactoring etc

This is fixed.


Mini-map URLs retain redundant parameters

From Kevin Klement:
"One minor "bug" I noticed is that when you click a circle from one number to go to another, the URL query parameter 'n=' is duplicated rather than replaced, and if you keep going you get more and more, e.g.:
When I went to 4.53 and then 24.6 and then 24.14 the URL looked like this:
https://principia.lib.uiowa.edu/?n=24.14&n=24.6&n=4.53
Where the second two n= parameters are probably redundant and ignored. This presumably should just be:
https://principia.lib.uiowa.edu/?n=24.14"

2457783bedf3677c9242047b458bf7f6c5ffa5f0


Why choose akita over ngrx?

Hi
I am in front of decieison about choosing between ngrx abd Akita to my Angular 8 project.
My app is not to big but for now with a lot of polling events fired to the app. So my event is build in kind of flow l until i havr the full data.
It means i need to show part of the data each time i got event.
i did not find realy good comparison between them.
Could you tell me or point me to why should I choose Akita ?
My thought basiclly are:

ireduce the boilerplate
keep the store out of the "core" app.

What is the diffrent between ngrx entity to akita?
Sorry If its not the right place.
Thanks

On the "10 Reasons" page, under bullet point 6, you have a link that goes to blog posts (https://netbasal.gitbook.io/akita/general/blog-posts) which does not exist.


[Feature Request] Add torch.bernoulli operation

Is your feature request related to a problem? Please describe.
Currently, tt doesn't support bernoulli operation to run on NPU.
Describe the solution you'd like
Impl a PRNG algo or use hardward PRNG.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Resolved in #13921


OAuth1 client using deprecated Faraday method

Environment details

OS: MacOS 11.6.1
Ruby version: jruby-<IP_ADDRESS>
Gem name and version: signet 0.14

Steps to reproduce

use faraday: gem 'faraday', '~> 1.8.0'
create a faraday connection: @connection = Faraday.new
create an oauth1 http client: @http_client = Signet::OAuth1::Client.new(...)
use the connection when fetching: @http_client.fetch_protected_resource(:connection => @connection)
See warn logs:

[2021-12-08T16:08:28.968Z] WARNING: `Faraday::Request#method` is deprecated; use `#http_method` instead. It will be removed in or after version 2.0.
[2021-12-08T16:08:28.968Z] `Faraday::Request#method` called from /ci/ci_state/ruby_bundle/jruby/2.5.0/gems/signet-0.14.0/lib/signet/oauth_1/client.rb:946:in `generate_authenticated_request'
[2021-12-08T16:08:28.968Z] WARNING: `Faraday::Request#method` is deprecated; use `#http_method` instead. It will be removed in or after version 2.0.
[2021-12-08T16:08:28.968Z] `Faraday::Request#method` called from /ci/ci_state/ruby_bundle/jruby/2.5.0/gems/signet-0.14.0/lib/signet/oauth_1/client.rb:946:in `generate_authenticated_request'
[2021-12-08T16:08:28.968Z] WARNING: `Faraday::Request#method` is deprecated; use `#http_method` instead. It will be removed in or after version 2.0.
[2021-12-08T16:08:28.968Z] `Faraday::Request#method` called from /ci/ci_state/ruby_bundle/jruby/2.5.0/gems/signet-0.14.0/lib/signet/oauth_1/client.rb:946:in `generate_authenticated_request'

It seems that the usage of method needs to be replaced with http_method

Thanks! Yes, this should get updated.


Unhandled Promise Rejection on Agent Startup

Every time my Agent Docker-Container (graphprotocol/indexer-agent:sha-4d50de5) starts, I get this error:
{
    "level": 40,
    "time":<PHONE_NUMBER>715,
    "pid": 1,
    "hostname": "2080bef9d9ee",
    "name": "IndexerAgent",
    "err": {
        "type": "IndexerError",
        "message": "Unhandled promise rejection",
        "stack": "IndexerError: Unhandled promise rejection\n    at Object.indexerError (/opt/indexer/packages/indexer-common/dist/errors.js:97:12)\n    at process.<anonymous> (/opt/indexer/packages/indexer-agent/dist/commands/start.js:212:39)\n    at process.emit (events.js:321:20)\n    at process.EventEmitter.emit (domain.js:482:12)\n    at processPromiseRejections (internal/process/promises.js:209:33)\n    at processTicksAndRejections (internal/process/task_queues.js:98:32)",
        "code": "IE035",
        "explanation": "https://github.com/graphprotocol/indexer/blob/master/docs/errors.md#ie035",
        "cause": {
            "type": "Error",
            "message": "call revert exception (method=\"getReserves()\", errorSignature=null, errorArgs=[null], reason=null, code=CALL_EXCEPTION, version=abi/5.0.9)",
            "stack": "Error: call revert exception (method=\"getReserves()\", errorSignature=null, errorArgs=[null], reason=null, code=CALL_EXCEPTION, version=abi/5.0.9)\n    at Logger.makeError (/opt/indexer/node_modules/@ethersproject/logger/lib/index.js:179:21)\n    at Logger.throwError (/opt/indexer/node_modules/@ethersproject/logger/lib/index.js:188:20)\n    at Interface.decodeFunctionResult (/opt/indexer/node_modules/@ethersproject/abi/lib/interface.js:286:23)\n    at Contract.<anonymous> (/opt/indexer/node_modules/@ethersproject/contracts/lib/index.js:319:56)\n    at step (/opt/indexer/node_modules/@ethersproject/contracts/lib/index.js:46:23)\n    at Object.next (/opt/indexer/node_modules/@ethersproject/contracts/lib/index.js:27:53)\n    at fulfilled (/opt/indexer/node_modules/@ethersproject/contracts/lib/index.js:18:58)\n    at processTicksAndRejections (internal/process/task_queues.js:97:5)",
            "reason": null,
            "code": "CALL_EXCEPTION",
            "method": "getReserves()",
            "errorSignature": null,
            "errorArgs": [null],
            "address": "0x588E0e70a7565552300C19F59155d0Cf21065fBA",
            "args": [],
            "transaction": {
                "data": "0x0902f1ac",
                "to": "0x588E0e70a7565552300C19F59155d0Cf21065fBA"
            }
        }
    },
    "msg": "Unhandled promise rejection"
}

The call fails for the obvious reason that this address is not a contract on Mainnet (or Rinkeby or Ropsten).
The Agent keeps running, but never fetches the $DAI variable, which may or may not be related. As Node tends to ignore code paths once an unhandled rejection occurs, I'd guess this is somewhere on the $DAI fetching path.

@saschagoebel What version of indexer-agent are you running?

@saschagoebel What version of indexer-agent are you running?

@Jannis graphprotocol/indexer-agent:sha-4d50de5 which is 0.9.0-alpha.2
I updated my testnet scripts, so I don't think there are any obvious mistakes. Only difference are the config changes as noted in the ReadMe (https://github.com/graphprotocol/mission-control-indexer) and I'm using an operator account now, so the mnemonic is for the operator and the address points to my lock contract.
Is there a newer docker image I can (semi safely) try?

@Jannis graphprotocol/indexer-agent:sha-4d50de5 which is 0.9.0-alpha.2
I updated my testnet scripts, so I don't think there are any obvious mistakes. Only difference are the config changes as noted in the ReadMe (https://github.com/graphprotocol/mission-control-indexer) and I'm using an operator account now, so the mnemonic is for the operator and the address points to my lock contract.
Is there a newer docker image I can (semi safely) try?

Docker-Compose:
thegraph-indexer-agent:
    image: graphprotocol/indexer-agent:sha-4d50de5
    command: "--indexer-geo-coordinates=49.460983 11.061859 --inject-dai"
    environment:
      INDEXER_AGENT_ETHEREUM: http://jsonrpc.ethereum.ethereum.mainnet.parity.archive-node-0032/
      INDEXER_AGENT_ETHEREUM_NETWORK: mainnet
      INDEXER_AGENT_MNEMONIC: some funny words that make up a secret phrase
      INDEXER_AGENT_INDEXER_ADDRESS: "0x..."
      INDEXER_AGENT_INDEXER_GEO_COORDINATES: 49.460983 11.061859
      INDEXER_AGENT_INDEX_NODE_IDS: thegraph_index_0001
      INDEXER_AGENT_GRAPH_NODE_QUERY_ENDPOINT: http://xxx:8000
      INDEXER_AGENT_GRAPH_NODE_STATUS_ENDPOINT: http://yyy:8030/graphql
      INDEXER_AGENT_GRAPH_NODE_ADMIN_ENDPOINT: http://yyy:8020
      INDEXER_AGENT_NETWORK_SUBGRAPH_ENDPOINT: https://gateway.network.thegraph.com/network
      INDEXER_AGENT_PUBLIC_INDEXER_URL: https://indexer.thegraph.anyblock.net/
      INDEXER_AGENT_INDEXER_MANAGEMENT_PORT: 8000
      INDEXER_AGENT_POSTGRES_HOST: zzz
      INDEXER_AGENT_POSTGRES_PORT: 5432
      INDEXER_AGENT_POSTGRES_DATABASE: indexer-agent
      INDEXER_AGENT_POSTGRES_USERNAME: secret
      INDEXER_AGENT_POSTGRES_PASSWORD: changeme
      INDEXER_AGENT_INJECT_DAI: "true"
      INDEXER_AGENT_DAI_CONTRACT: "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48"
    extra_hosts:
      - jsonrpc.ethereum.ethereum.mainnet.parity.archive-node-0001:aaa
      - jsonrpc.ethereum.ethereum.mainnet.parity.archive-node-0032:bbb
    ports:
      - "8888:8000"
      - "7302:7300"
    network_mode: bridge
    restart: unless-stopped

Docker-Compose:
thegraph-indexer-agent:
    image: graphprotocol/indexer-agent:sha-4d50de5
    command: "--indexer-geo-coordinates=49.460983 11.061859 --inject-dai"
    environment:
      INDEXER_AGENT_ETHEREUM: http://jsonrpc.ethereum.ethereum.mainnet.parity.archive-node-0032/
      INDEXER_AGENT_ETHEREUM_NETWORK: mainnet
      INDEXER_AGENT_MNEMONIC: some funny words that make up a secret phrase
      INDEXER_AGENT_INDEXER_ADDRESS: "0x..."
      INDEXER_AGENT_INDEXER_GEO_COORDINATES: 49.460983 11.061859
      INDEXER_AGENT_INDEX_NODE_IDS: thegraph_index_0001
      INDEXER_AGENT_GRAPH_NODE_QUERY_ENDPOINT: http://xxx:8000
      INDEXER_AGENT_GRAPH_NODE_STATUS_ENDPOINT: http://yyy:8030/graphql
      INDEXER_AGENT_GRAPH_NODE_ADMIN_ENDPOINT: http://yyy:8020
      INDEXER_AGENT_NETWORK_SUBGRAPH_ENDPOINT: https://gateway.network.thegraph.com/network
      INDEXER_AGENT_PUBLIC_INDEXER_URL: https://indexer.thegraph.anyblock.net/
      INDEXER_AGENT_INDEXER_MANAGEMENT_PORT: 8000
      INDEXER_AGENT_POSTGRES_HOST: zzz
      INDEXER_AGENT_POSTGRES_PORT: 5432
      INDEXER_AGENT_POSTGRES_DATABASE: indexer-agent
      INDEXER_AGENT_POSTGRES_USERNAME: secret
      INDEXER_AGENT_POSTGRES_PASSWORD: changeme
      INDEXER_AGENT_INJECT_DAI: "true"
      INDEXER_AGENT_DAI_CONTRACT: "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48"
    extra_hosts:
      - jsonrpc.ethereum.ethereum.mainnet.parity.archive-node-0001:aaa
      - jsonrpc.ethereum.ethereum.mainnet.parity.archive-node-0032:bbb
    ports:
      - "8888:8000"
      - "7302:7300"
    network_mode: bridge
    restart: unless-stopped

Yes, make sure to update to v0.9.1: https://github.com/graphprotocol/indexer/releases/tag/v0.9.1
This was fixed in https://github.com/graphprotocol/indexer/pull/164 (for v0.9.0-alpha.3) but for mainnet, I'd strongly recommend updating all the way to 0.9.1.

Yes, make sure to update to v0.9.1: https://github.com/graphprotocol/indexer/releases/tag/v0.9.1
This was fixed in https://github.com/graphprotocol/indexer/pull/164 (for v0.9.0-alpha.3) but for mainnet, I'd strongly recommend updating all the way to 0.9.1.

Dammit! I saw that announcement but then lost track of all the new channels and somehow forgot.
Thanks!
P.S.: The ReadMe should probably be updated as well

Dammit! I saw that announcement but then lost track of all the new channels and somehow forgot.
Thanks!
P.S.: The ReadMe should probably be updated as well

The official README is https://github.com/graphprotocol/indexer/ now and the release announcements point to the corresponding Docker images (also tagged as e.g. ghcr.io/graphprotocol/indexer-agent:v0.9.1 now).
We'll move some of the mission control docs and FAQ to the official docs soon.
Could you close the issue once you've upgraded and the problem has resolved? Or follow up if the problem persists?

The official README is https://github.com/graphprotocol/indexer/ now and the release announcements point to the corresponding Docker images (also tagged as e.g. ghcr.io/graphprotocol/indexer-agent:v0.9.1 now).
We'll move some of the mission control docs and FAQ to the official docs soon.
Could you close the issue once you've upgraded and the problem has resolved? Or follow up if the problem persists?

Everything seems to work fine now. Thanks :-)

Everything seems to work fine now. Thanks :-)


fix(helm): correct invalid ConfigMap template

This corrects a bug in https://github.com/cybozu-go/accurate/pull/142. Without this fix, the Helm chart rendering is erroring out with:
Error: Error: template: accurate/templates/deployment.yaml:18:28: executing "accurate/templates/deployment.yaml" at <include (print $.Template.BasePath "/configmap.yaml") .>: error calling include: template: accurate/templates/configmap.yaml:24:20: executing "accurate/templates/configmap.yaml" at <.Values.controller.config.propagateLabelKeyExcludes>: can't evaluate field Values in type []interface {}

Sorry for this, but this is a blocking error that will require a new patch release (of the Helm chart, at least).
CC @zoetrope @ymmt2005

@zoetrope please release a new Helm chart. Thank you.

@erikgb @ymmt2005
Thanks.
https://github.com/cybozu-go/accurate/releases/tag/accurate-chart-0.7.5 released


Managedscript get-sosreport to collect sosreports for troubleshooting

This script was written in order to suffice the need of capturing an sosreport proactively from nodes when required node-level troubleshooting and/or to assist in pursuit of RCA's when required.

@ehvs - Also, I've noticed that you submitted the PR from your local main branch rather than a local feature or topic branch for your changes which is not a good practice and may have some potential conflicts.
I would suggest you to create a new branch from your local main, apply the changes there, and then create a pull request from that new branch. This will align with our best practices and helps maintain the structural of our project's codebase.

Closing pull request as per suggestion.


Remove bullets from class fields and methods

Fixes https://github.com/processing/p5.js/issues/6170#issuecomment-1615190776
Changes
When adding support for bullets in docs, while I made sure method parameters didn't get bullets, class field and method lists got bullets. This corrects the issue and removes bullets from those lists.
Screenshots of the change
Before

After

Looks good. Thanks!
Also just took this opportunity to regenerate reference.js and package-lock.json to latest versions.


Respect XDG basedir spec for global configuration file

To conform to the XDG basedir spec, bundler's config file ought to be stored at ${XDG_CONFIG_HOME:-$HOME/.config}/bundler/config
I'm not completely sure what other files are stored under ~/.bundle, but there are other XDG-defined directories for cache and runtime files, if so needed.
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

a) that's a breaking change
b) dumb question but what does XDG stand for, and what makes it the authoritative spec for how command line apps store things on disk?

doesn't need to be a breaking change. most tools that have migrated do so by first checking if ~/.my-app exists and using it if so. If it doesn't exist, then the XDG settings are honored. This way people can opt-in by moving the files themselves (or removing the old ones). Some tools go a step further and migrate the files automatically.
XDG is a group that works on interoperability between *nix systems. The basedir spec is just one aspect of the larger focus of the group. The primary benefit to users is: standardized configurability by users/sysadmins across apps. (And it falls in lines with Apple guidelines on not polluting userspace)
git is the largest project that I'm aware of that conforms. keybase does as well. I've seen many others but can't recall them offhand.

The problem is not limited to the configuration file, but also cache files.
Cache files should be stored at
${$XDG_CACHE_HOME:-$HOME/.cache}/bundler

instead of ~/.bundler/cache.
If we need to appeal to authority, we can add Firefox, Thunderbird, Chromium and Inkscape to the list of apps that follow the XDG Basedir spec and do not clutter our lovely $HOMEs. :)

Doesn't seem like anyone on the team is too excited about implementing this, @jasonkarns or @gioele would you want to work on a PR? (we aren't guaranteed to merge it, but it would help make your case)

Is anybody already working on this?

@valeth not at the moment!

I can give it a shot soon.
On Jun 4, 2017 5:13 PM, "Samuel Giddins"<EMAIL_ADDRESS>wrote:

@valeth https://github.com/valeth not at the moment!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bundler/bundler/issues/4333#issuecomment-306067358,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHUpF1MfdaIsfjoZcUCQSujiUn4YWx_ks5sAx3mgaJpZM4HpeFb
.

This has been added in #6024


Fix crash when language resource is null

Issue

Overview (Required)
Like an after party session, If topic color is null it is crash.
So I set the default value.
and
if topic or room is null, I set View.GONE to session tag.
Links

Screenshot

Before
After

fixed f92eed8

Thank you for ! LGTM 💯