Kong 0.10.3 Load balancer sending target name instead of upstream

I'm trying to use Kong's internal LB to share traffic between the backends, but I get a 403 error as Kong sends the target (the target machine hostname) instead of the upstream (url). As my backends are running nginx, serving multiple apis, they can't figure out what to do with the hostname. Here's an example line from the nginx log:
192.168.xxx.xxx "xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx" - "-" [07/Jun/2017:16:24:27 +0100] - - https api-backend01 "GET / HTTP/1.1" 403 135 0.000 - - - "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0" "-"  - OK "max-age=0" - "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"

Have you tried enabling the preserve_host property on the API?

(Also the meaning of this log entry is not very clear as you have a custom Nginx format. Some additional clarify would be helpful here :) ).

I'm sorry for not explaining further the log in advance, the relevant part here is "api-backend01", this is the url that is being requested to nginx.
Indeed I tried the preserve_host, but in that case, kong will send the url I'm using for kong itself.
To clarify: kong has an url like api-gateway.domain.com, and my upstream is api01.domain.com, the target being api-backend01. Without preserve_host, nginx gets api-backend01 as the request url, with preserve_host on, nginx gets api-gateway.domain.com. What I'm looking for is to send api01.domain.com.
I hope I was clear enough, this is a bit messy, sorry.

Sorry, I'm still not quite clear. preserve_host is used to maintain the Host header, but you're talking about the request url. What specific part of the upstream request that Kong is sending are your upstreams having troubles with?

preserve_host is used to maintain the Host header, but you're talking about the request url.
I took the time to look around other sites just to make sure I wasn't about to say anything idiotic: the host header contains the base url of the request, which I don't want to preserve, I don't want api-gateway.domain.com to be sent to the targets, as that will send the application into an infinite loop.

But this part of the log entry doesn't look like a URL?
Exactly!! Maybe I didn't use the best words to express myself, I'll try again: api-backend01 is the hostname of the target machine, that's the entry I create on the targets of the upstream I want my requests to be directed at. Kong, while sending the request to the target, sends the target name (this hostname), instead of the upstream url, which will then be interpreted by nginx as a bad request.

I hope this was clearer this time.

I think I understand. You didn't say anything idiotic, it took me a minute to wrap my head around this.
This is expected behavior- Kong will either send, in the upstream request Host header, the Host header present in the downstream request (that it received from the client), or it will send the name:port of the upstream target used to initiate the request. It sounds like you want a third option, but how would Kong know what the name of this value should be? In your case it is api01.domain.com, but Kong doesn't know anything about api01.domain.com, hence it cannot possibly set the Host header as such.
I think this is an interesting feature/case. From my mind, it would require defining an additional value on either the target or the API object to override the Host header (e.g., we dont want the client Host header, and we dont want the host defined by the name of the target). Sounds like it needs some thought on our end.
In your case, the workaround would be to have your backends accept requests from either the Host header the client sends (with preserve_host enabled), or the upstream target name (or alternatively, name the targets in such a manner that they produce a Host header acceptable to your backend).

Thanks for taking the time to understand my problem, there's only one thing I wasn't able to comprehend: why isn't Kong aware of api01.domain.com? This being the upstream_url, it's saved in kong's database.
Just to be clear, I'm currently not using the upstreams feature due to this issue, and I'm balancing the backend connections with an haproxy, and kong sends the upstream_url (api01.domain.com), which, in my opinion should be favoured, instead of the targets ips/hostnames. Or it could be a third option as you mentioned, the thing is that, the way I see it, the upstreams feature introduces a behaviour that is unexpected for me. But I'm sure other people will disagree, that's just my two cents :)

why isn't Kong aware of api01.domain.com? This being the upstream_url, it's saved in kong's database.

Ah, my mistake. I wasn't aware that the api01.domain.com was the actual upstream_url. Given this, you could use Kong's built-in load balancer to handle traffic based on DNS names:
https://getkong.org/docs/0.10.x/loadbalancing/#dns-based-loadbalancing
So if api01.domain.com is actually resolvable, you could define it with multiple A/AAAA records (or CNAME, or SRV), and do your load balancing that way, instead of relying on haproxy. Kong should send the upstream Host header as the name of the upstream_url in this case, which sounds like the behavior you're looking for.

It seems that I'm really doing something very weird here, but I'll take the time to explain, as it might be useful for you guys :)
The api01.domain.com is not resolvable, I was using the hosts file to resolve it, something that is not very practical once we have more than one backend serving the same api. I also don't want to run an extra service to do local DNS exclusively, which this makes Kong's LB a no go. If I have to run an extra service, I'd rather run an haproxy that takes care of both name resolving (in this case) and load balancing.

This seems very much like an edge case, then, and I'm not sure that adding more tunable knobs to support such an unlikely scenario is worth it. Kong supports the desired features (serving the upstream_url as part of the upstream Host header), just not in this very corner case (where DNS is used abnormally).

@tieske any thoughts here?

Sorry but i have a trouble about Upstreams and targets ,I config Kong like this:
API  A has "hosts: test.kong.com" with "upstream_url: http://test.abc.com/" and "uris: /aa"
And one upstream name "test.abc.com" have two targets : <IP_ADDRESS>:80 & <IP_ADDRESS>:80
When i call POST request to : test.kong.com/aa/path..., but Kong response 404 error and i sure Kong dont forward request to target. I dont know what wrong with my config, please help. Thanks :(

@hungpt91 please do not hijack threads for your own unrelated questions. Please use the Kong mailing list or Gitter for such support questions. Thank you.

if I understand correctly you have api01.domain.com defined as the name of your Kong upstream entity. You add targets to this upstream entity for Kong to balance the requests over, and you set in your api the upstream_url=http://api01.domain.com/and/maybe/a/path.
The upstream name is pure internal to Kong, and should never be used in a host header imo. The proper implementation would be to have your upstream services accept your externally used hostname. In your case that would be api-gateway.domain.com.
If we were to support this, then the proper way would be to define a host_header field on the upstream entity. If that is not set, then behavior remains as it currently is (depending on preserve_host setting). If that property would be set, then all requests forwarded to the targets in this upstream would get the host header as specified in the host_header property (and then the whole X-Forwarded-host discussion starts again...)
Anyway, seems like an edge case to me. Why would you have upstream services responding only to a non-existing hostname?

Closing as stale; this seems like an edge case with workarounds available. Feel free to re-open if there are further questions here. Thanks!


compilation error from newNodeFxns ?

I'm not sure exactly what's going wrong here, but there's a compilation error that I'm guessing comes from the newNodeFxns changes.  This model compiles fine under v0.5-1, but not on the current devel.
this is not a minimalistic example
data file and script can be downloaded here

getNodeFunctionIndexedInfo needed to be added to eigenizeCallsBeforeRecursing to be handled by eigenize_doNotRecurse.
A brief explanation:  In the newNodeFxns system, a line of BUGS code leads to a single instance of a class, with calculate etc. functions taking a single argument (INDEXEDNODEINFO_) that is an integer indicating which row of indexing information should be used.  Indexing information refers to indices from for-loops as well as scalar partially-evaluated values.  getNodeFunctionIndexedInfo(INDEXEDNODEINFO_, n) simply returns the value from row = INDEXEDNODEINFO_ and column = n of the table of indexing information.
The fact that there was a hitch during eignenization for a use of getNodeFunctionIndexedInfo suggests that our test suite doesn't contain much (or any) variety of vectorized expressions in BUGS code, probably because it comes from classic BUGS examples in which vectorized expressions weren't supported.

Thanks for the quick fix, and the explanation @perrydv.  It works without a hitch.
FYI, running on v0.6 speeds up the MCMC by 3x for this model.  That's something to be proud of.


Service constr exp

Add Service Constructor expression
service-constructor-expr := [annots] service service-body-block
service-body-block := { service-method-defn* }
service-method-defn :=
metadata
[resource]
function identifier function-signature method-defn-body
Check List

[ ] Read the Contributing Guide
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Codecov Report

Merging #23507 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #23507   +/-   ##
=======================================
  Coverage   14.59%   14.59%
=======================================
  Files          51       51
  Lines        1411     1411
  Branches      219      219
=======================================
  Hits          206      206
  Misses       1189     1189
  Partials       16       16

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 ec3a068...ffc1a69. Read the comment docs.


Does not find "PowerShell 7 (x64)"

Environment
Windows build number: [run "ver" at a command prompt] Microsoft Windows [Version 10.0.18363.836]
PowerToys version: V0.18.2
PowerToy module for which you are reporting the bug (if applicable): Launcher

Steps to reproduce
Does not find Evernote "PowerShell 7 (x64)" app. However, finds Windows PowerShell
Expected behavior
Finds "PowerShell 7 (x64)"
Actual behavior
Does not find, only Windows PowerShell

Screenshots

Just write psh. On my desktop it's work.

Just write psh. On my desktop it's work.

psh does not work on my desktop.

I think he means pwsh?

I think he means pwsh? Jk psh works for me too

Also, pwsh does not work on my desktop.

Now I have to type powershell 7... It works.

My gut says most of these quirks are fixed with 0.19.  We added in environment path by default and did a lot of quality of search improvements

This is under .19 RC build.
For pwsh / psh, neither of this commands work in run prompt on my local machine at least.

I close this issue because it seems to be solved.


1.1.2+1.21.4

Version Bump, no actual code changes.

Thanks for your contribution! To maintain consistency with previous pull requests, I have updated the title of your pull request. The update will be available soon on Modrinth.


Feature/bug comments

enhancement in the comments front-end, container, input and list of comments.

Change name button "save comment" to "Coment".
Text with much lines, dont save.


positioning of plotting windows

I am trying to position the plot widows. Can we add a general setGeometry method to the BasePlot object?
The QtPlot object has member plotQ.win which is a pyqtgraph.GraphicsWindow. I can call plotQ.win.setGeometry to set the position (this works), but if I look at the object I get the following error:
> plotQ.win
===== Remote process raised exception on request: =====
Traceback (most recent call last):
  File "/usr/local/lib/python3.4/dist-packages/pyqtgraph/multiprocess/remoteproxy.py", line 213, in handleRequest
    result = getattr(opts['obj'], opts['attr'])
AttributeError: 'GraphicsWindow' object has no attribute '_ipython_display_'

===== Local Traceback to request follows: =====
===== Remote process raised exception on request: =====
Traceback (most recent call last):
  File "/usr/local/lib/python3.4/dist-packages/pyqtgraph/multiprocess/remoteproxy.py", line 213, in handleRequest
    result = getattr(opts['obj'], opts['attr'])
AttributeError: 'GraphicsWindow' object has no attribute '_repr_png_'
...

@eendebakpt  looking at this again I think we can close this issue, you are seing an error because you are using ipython/jupyter!
Whenever you return an object to the ipython console, or the jupyter html notebook they will try to find a repr  function, and the pyqt remote proxies will happily accept any function call and proxy it to the real object which then will raise an exception and then the proxy raises another exception that has a different type than what the console/ notebook expect.
Thas is a classic failure mode of poorly designed systems, like the remote pyqtgraph (which was just designed for speed, not interactive use).

@unga In #387 there is no issue any more, so in that sense the issue can be closed. Related there are the following two issues:

There should be a generic .setGeometry that is both valid for the Qt and Matplotlib style windows.
In #387 the plotting object is a subclass of QWidget. This has both advantages and disadvantages and we should decide whether we want this or not.

@peendebak  yes, because 387 uses pyqtgraph the way it's meant to be used :D
Possibly true that there should be .setGeometry but in matplotlib that gets tricky ( @jenshnielsen  may know a lot more about this than me though) it also gets tricky in the web world where one does not take control of the desktop behavior!

for pyqtgraph this can be solved like this:
https://github.com/qdev-dk/Qcodes/commit/ae32c1a848b71a7a4ccd473e00b937c7ed06bfd0
Wether or not we want to merge this back in qcodes it's something we can decide here!
@jenshnielsen  you call the shot on this one!

Probably we should expose a setting from config that sets a default position. That way you can configure your measurement computer with say the notebook/python console on the left and windows always popping up to the right of that and if you don't set anything in config it will default to the current behaviour.
The tricky part is handling multi monitor in a way thats both general enough and actually useful

For pyqtgraph this is possible via fig_x_position and fig_y_position https://github.com/QCoDeS/Qcodes/blob/master/qcodes/plots/pyqtgraph.py#L68


Context objects during parsing

I'm using nearley to parse VERY LARGE files (GB). So I don't want to construct the tree, I just want to parse and chunk by chunk eval my data and import them.

What is the best way to approach this?
How can I use custom context object/callback during parsing so that I can call extern object during it?

I’m afraid I don’t understand what you mean by “chunk by chunk eval”.
Unless there are natural break points in your files, that you can detect before parsing—eg a new line token to separate unrelated parses—I don’t see how you would “split up” parsing.
You almost certainly want to use a tokenizer (moo) for this. You might be better off not using nearley at all, depending on what you’re trying to parse, and how complicated the syntax is.
I’m not sure what you mean about context, either :-) Perhaps you should describe your use case in more detail?
Sent with GitHawk

Imagine a situation like this:
INSERT INTO table (id, name, phone, date) VALUES
  (1, 'Phil', '444444444', NULL),
  (2, 'John', '333333333', NULL),
  (3, 'Anne', '777777777', NULL),
  ...
  10.000 rows

I don't want to parse and create a tree of my data, but to create a processor based on a grammar, that fires an event and call a custom callback for example on every VALUE row, with some custom data as context like the info that I parse before in the INSERT INTO row.
But there are many other situation where I need to use a grammar to create a processor that react to a text and does not simply construct a tree.
I did many times processors like that using Javacc. Can I do the same with nearly? Maybe it's my fault that I don't know very well the library.

Another example about the possibility to use a context object in postprocessor.
I would like to attach an custom object to the parser, in this way:
const parser = new nearley.Parser(myGrammar);
parser.ctx = myCustomObject;

and to be able to access this object in the post processor
function postprocessor (d,pos,err,ctx) {
    ...
    ctx.doSomething(d);
}

in do something for example I can start to import data in the db, or other stuff.

Here is an update with example. Look at this branch
and try
node bin/nearley-test.js -q examples/js/events-stream.js < examples/events-stream.data

you can see that:

I had to fix the nearley-test.js using readline because if a stream read is broke in the middle of a moo token we have an error
I'm not yet able to process all the events even if they are an "iterative" sequence, because - I believe - nearley accomulates stack calls
finally I want to be able to call an external function on every event to process my data (try to look at file events-stream.ne)

I’m sorry, but I don’t think you can use Nearley to do what you want. Nearley uses the Earley algorithm, which brings many of the benefits listed in the readme; unfortunately for your use case, Earley is a top-down parser, not a bottom-up one.
If you’re interested, you might find hardmath123’s blog post introducing the algorithm interesting: https://hardmath123.github.io/earley.html
Sent with GitHawk

@dashie We had a similar usecase. This patch worked for us. I haven't tested it with your usecase, though. It seems more complicated than mine.
// nearley.js:82
State.prototype.finish = function() {
  if (this.rule.postprocess) {
    // Add context as the 4th argument
    this.data = this.rule.postprocess(this.data, this.reference, Parser.fail, this.context);
  }
};

// grammar.ne
main -> "foo" {% (d, _, _, c) => c.addVertex(d) %}

// nearley.js:313
var next = state.nextState({
  data: value,
  token: token,
  isToken: true,
  reference: n - 1,
  // Add context to the state
  context: this.options.context || {}
});

const g = nearley.Grammar.fromCompiled(grammar)
const context = { addVertex: (a) => { ... } }
// Pass context in the options.
const opts = { context }
var parser = new nearley.Parser(g, opts);


DR dashboard metrics changes - WIP

Metrics changes in ramen: https://github.com/RamenDR/ramen/pull/784

/hold

issue:

/retitle DR dashboard metrics changes - WIP
now we have 4.13 branches, we need to add BZ number to the title for backport PRs now... not for master...

/hold cancel

/test odf-console-e2e-aws

/lgtm

/cherrypick release-4.13

/cherrypick release-4.13-compatibility


Global state edition

This PR aims to close #346.

this PR introduces some latency when running with npm run dev (I think). The latency is acceptable when running in production though.

Looks good, just a few questions. Since this PR will require a lot of changes on the ongoing branches, could you maybe add an overview of those changes? Such as the use of useSwrWithEdition, the path transformer, an explanation for the changed pathnames, etc. Could you also add some tests?

What kind of tests are you thinking of? (Also not the urgency behind this PR)

This PR essentially introduces only 2 functions.
First we have  useSwrWithEdition this hook takes the same arguments as useSwr but will make sure the call is queried with the current edition id. The back end is written in a way that every search/by-edition expects the same argument edition so this function generalizes just that.
Second we have useEditionPathTransformer this hook returns a function that when provided with a front end path, return the same path but with the front end edition query. Whenever you route to a page that is edition dependent, you should use this transformer.
I hope this is clear. If not, please say so.

This PR essentially introduces only 2 functions. First we have useSwrWithEdition this hook takes the same arguments as useSwr but will make sure the call is queried with the current edition id. The back end is written in a way that every search/by-edition expects the same argument edition so this function generalizes just that.
Second we have useEditionPathTransformer this hook returns a function that when provided with a front end path, return the same path but with the front end edition query. Whenever you route to a page that is edition dependent, you should use this transformer.
I also implemented a useOwnUser hook. This hook just does what it says.
I hope this is clear. If not, please say so.

Can you pin this on discord for @ruvmello and @thvmulle so they are aware of the changes as well?


Datastore keys are not correctly encoded as strings

Datastore Key structs should be encoded to strings, similar to time.Time structs. In general it would be nice if this library had a way to insert information about custom serializations of specific types.
For now, in our repo, we have fixed this issue by vendoring and changing line 267 as follows:
		} else if (t.PkgPath() == "time" && t.Name() == "Time") || ((t.PkgPath() == "google.golang.org/appengine/datastore" || t.PkgPath() == "cloud.google.com/go/datastore") && t.Name() == "Key") {
			// timestamps are serialised to strings as are datastore keys.

I just found the CustomFn code. Seems like that will work for us.


Refactors with pathlib

This makes stuff more readable and also reduces the number of imports.

Intro: Welcome doesn't have explanation.txt or goal.txt, and they're not overridden, so tests are failing :/


New task: Add PAMPA Permeability, NCATS dataset

Add dataset from https://tdcommons.ai/single_pred_tasks/adme/#pampa-permeability-ncats

I creat a PR for this, it was a great resource. Thanks for suggestion.


Trigger Agent throws a "	undefined method `<<' for nil:NilClass" error

the code is
{
"expected_receive_period_in_days": "2",
"keep_event": "false",
"rules": [
{
"type": "field>=value",
"value": "4.0",
"path": "{{magnitude}}"
}
],
"message": {{magnitude}} earthquake"
}
also tried to use regex, come out the same error:
"rules": [
{
"type": "regex",
"value": "[4,5,6,7,8,9].*",
"path": "{{magnitude}}"
}
And I have a another trigger Agent work fine.
         undefined method `<<' for nil:NilClass /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/jsonpath-0.5.7/lib/jsonpath.rb:53:in `initialize' /home/huginn/huginn/lib/utils.rb:71:in `new' /home/huginn/huginn/lib/utils.rb:71:in `values_at' /home/huginn/huginn/lib/utils.rb:60:in `value_at' /home/huginn/huginn/app/models/agents/trigger_agent.rb:74:in `block (2 levels) in receive' /home/huginn/huginn/app/models/agents/trigger_agent.rb:73:in `map' /home/huginn/huginn/app/models/agents/trigger_agent.rb:73:in `block in receive' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/relation/delegation.rb:46:in `each' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/relation/delegation.rb:46:in `each' /home/huginn/huginn/app/models/agents/trigger_agent.rb:69:in `receive' /home/huginn/huginn/app/jobs/agent_receive_job.rb:8:in `perform' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activejob-<IP_ADDRESS>/lib/active_job/execution.rb:32:in `block in perform_now' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:117:in `call' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:555:in `block (2 levels) in compile' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:505:in `call' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:498:in `block (2 levels) in around' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:343:in `block (2 levels) in simple' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/i18n-0.7.0/lib/i18n.rb:257:in `with_locale' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activejob-<IP_ADDRESS>/lib/active_job/translation.rb:7:in `block (2 levels) in <module:Translation>' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:441:in `instance_exec' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:441:in `block in make_lambda' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:342:in `block in simple' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:497:in `block in around' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:505:in `call' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:498:in `block (2 levels) in around' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:343:in `block (2 levels) in simple' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activejob-<IP_ADDRESS>/lib/active_job/logging.rb:23:in `block (4 levels) in <module:Logging>' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/notifications.rb:164:in `block in instrument' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/notifications/instrumenter.rb:20:in `instrument' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/notifications.rb:164:in `instrument' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activejob-<IP_ADDRESS>/lib/active_job/logging.rb:22:in `block (3 levels) in <module:Logging>' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activejob-<IP_ADDRESS>/lib/active_job/logging.rb:43:in `block in tag_logger' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/tagged_logging.rb:68:in `block in tagged' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/tagged_logging.rb:26:in `tagged' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/tagged_logging.rb:68:in `tagged' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activejob-<IP_ADDRESS>/lib/active_job/logging.rb:43:in `tag_logger' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activejob-<IP_ADDRESS>/lib/active_job/logging.rb:19:in `block (2 levels) in <module:Logging>' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:441:in `instance_exec' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:441:in `block in make_lambda' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:342:in `block in simple' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:497:in `block in around' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:505:in `call' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:92:in `__run_callbacks__' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:778:in `_run_perform_callbacks' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:81:in `run_callbacks' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activejob-<IP_ADDRESS>/lib/active_job/execution.rb:31:in `perform_now' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activejob-<IP_ADDRESS>/lib/active_job/execution.rb:21:in `execute' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/activejob-<IP_ADDRESS>/lib/active_job/queue_adapters/delayed_job_adapter.rb:34:in `perform' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/backend/base.rb:100:in `block in invoke_job' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:61:in `block in initialize' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:66:in `execute' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:40:in `run_callbacks' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/backend/base.rb:97:in `invoke_job' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/worker.rb:224:in `block (2 levels) in run' /usr/local/lib/ruby/2.3.0/timeout.rb:91:in `block in timeout' /usr/local/lib/ruby/2.3.0/timeout.rb:101:in `timeout' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/worker.rb:224:in `block in run' /usr/local/lib/ruby/2.3.0/benchmark.rb:308:in `realtime' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/worker.rb:223:in `run' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/worker.rb:300:in `block in reserve_and_run_one_job' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:61:in `block in initialize' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:66:in `execute' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:40:in `run_callbacks' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/worker.rb:300:in `reserve_and_run_one_job' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/worker.rb:207:in `block in work_off' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/worker.rb:206:in `times' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/worker.rb:206:in `work_off' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/worker.rb:169:in `block (4 levels) in start' /usr/local/lib/ruby/2.3.0/benchmark.rb:308:in `realtime' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/worker.rb:168:in `block (3 levels) in start' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:61:in `block in initialize' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:66:in `execute' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:40:in `run_callbacks' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/worker.rb:167:in `block (2 levels) in start' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/worker.rb:166:in `loop' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/worker.rb:166:in `block in start' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/plugins/clear_locks.rb:7:in `block (2 levels) in <class:ClearLocks>' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:79:in `block (2 levels) in add' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:61:in `block in initialize' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:79:in `block in add' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:66:in `execute' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:40:in `run_callbacks' /home/huginn/huginn/vendor/bundle/ruby/2.3.0/gems/delayed_job-4.1.1/lib/delayed/worker.rb:165:in `start' /home/huginn/huginn/lib/delayed_job_worker.rb:6:in `run' /home/huginn/huginn/app/concerns/long_runnable.rb:71:in `block in run!'

Hi @gyaoshi,
the TriggerAgent expects the values in path to be a JSONPath, try using $.magnitude instead of {{magnitude}}.


Automatically Open any folder in VS code

Today, Frist time I tried vs code in the linux environment, and I'm facing a big problem.
When i try to open any folder on desktop by double clicking, it automatcally open in vs code.
But after uninstalling vscode I didn't face any types of problem like this with other editor like atom
Please help me out, I love vs code

https://github.com/Microsoft/vscode/issues/41037


Challenges in running multiple instances of twemproxy?

Hello, I have a question about running multiple instances of twemproxy, and specifically what happens when adding/removing memcached backends.
For instance, if I have two instances of twemproxy running with exactly the same configuration, and then need to add a new backend node, what risks are there in terms of having to synchronize the process restarts, etc?
Consider the following scenario:
twemproxy A refers to memcached servers 1, 2 and 3
twemproxy B refers to memcached servers 1, 2 and 3
At this point everything is in synch and working well.
What happens in this case if you:
Add server 4 to twemproxy A and restart the process
Wait 5 number of minutes
Add server 4 to twemproxy B and restart the process
In the 5 minutes between, are the two instances of twemproxy now using different ring/hashing algorithms?
Thanks in advance - just trying to get a feel for the best practices around using multiple instances of twemproxy.

HI @manjuraj ,
I have two twemproxy running in two different machine and both the twemproxy is connected to the same two redis which are running in another machine.
To avoid confusion Twemproxy 1 is running in Machine A, Twemproxy 2 is running Machine B and the two redis, Redis 1 and Redis 2 is running in machine C.
These 2 twemproxy were installed just to push the data in Redis.
Later, I installed 1 more Twemproxy 3 in Machine C where the Redis is running for reading the values from Redis, but it is behaving abnormally, I mean it is returning null value for that data also which is present in Redis.
If possible can you please give me some advice or abnormal behaviour by twemproxy while running in production. It will be really helpuful.
Thanks


[Suggestion] Add a checkbox for every function in the list when deleting function using command

OS: All
Build Version: 20200522.22
Repro Steps:

F1->PostgreSQL: Delete Functions...->Select the subscription and account->Select database
Check the Function list.

Actual:
There is no checkbox in Function list, we can only delete one Function at a time.

Suggestion:
Add a checkbox for every function, it is convenient to delete multiple function at one time.

While this is nice to have, we'll see if a user reports this before implementing


[BUG] Package cannot automatically update when the signing certificate has changed

Project
MSIX SDK (Package created using VS Community 2019 16.6.4)
Describe the bug
Package cannot automatically update when the signing certificate has changed.
To Reproduce

Sign and deploy your application using a certificate. You keep on using it and updating your app, and your user base grows.
Later on (two years in our case) the certificate is near expiration and we ask for another one. Due to changes in the Certificate Authority, or even ourselves if we move from one location to another, or whatever the reason, the new certificate is slightly different (maybe now it is all uppercase letters in the CN field).
Sign (with the new certificate) and deploy again your application, but in this case none of your users can update because of the following EventLog error (channel: Microsoft-Windows-AppXDeploymentServer/Operational):

Error	04/08/2020 12:44:09	AppXDeployment-Server	651	(3)
Error en la operación AppInstaller con el código de error 0x80070490. Detalle: No se ha encontrado el elemento.

If users manually force the installation of the package browsing to the webpage where it is published (by clicking in the "ms-appinstaller:?source=https://the.web.site.com/AppPackages/PackageProject.appinstaller" hyperlink) they receive the following error message:

The translation goes like:
Ask the developer for a new app package. This package may conflict with a package already installed, or it depends on things not installed here (package dependencies), or is made for a different architecture (0x80073CF3)

And in the EventLog (same channel as before):
Error	04/08/2020 12:58:35	AppXDeployment-Server	429	(4)
Windows cannot install package 967439b3-5b2b-4167-839c-0ba174a6c946_<IP_ADDRESS>_neutral_~_cb1zszxp1a70a because a different package 967439b3-5b2b-4167-839c-0ba174a6c946_<IP_ADDRESS>_neutral_~_wytc7bwvwy2aa with the same name is already installed. Remove package 967439b3-5b2b-4167-839c-0ba174a6c946_<IP_ADDRESS>_neutral_~_wytc7bwvwy2aa before installing.

Summing up, a conflict with a package with the same name that already exists, because the update is detected as a different package.
Expected behavior
There should be a way to keep on updating our applications despite changes in the signing certificate. Because of a company moving from one city to another, or a Certifcate Autority changing its policies (now enforces everything in upper cases). That shoudn't mean that our whole user base must do a manual uninstall and reinstallation of the application.
Screenshots
If applicable, add screenshots to help explain your problem.
Platform
x64 and x86 at least. Not tested in any other.
Additional context
This thread Updating existing app with new certificate UWP deals with the same problem. I suppose it does not matter what kind of target application you are making since the issue comes at the core of the distribution process. It is not so much what you are publishing but more the way to do it.

Thanks jagbarcelo for figuring this one out.
I can confirm this.
We have the exact same issue.
Our certificate ran out in May 2019, we updated to a new one (until 2021).
Result: All users who have the app with the old certificate installed, can't update to any new version with the new certificate since May 2019, without seeing the error message "this package may conflict with a package already installed".
Installation in our case: Also via an update url with appinstaller file.

We ran into this issue too, our Certificate Authority changed the "State" field (from shortname to fullname).
We had to manually uninstall all apps, install the update and configure them again.
The issue is the "Family name" (app manifest -> Packaging tab). This name is a Hash of all the characters in the signin certificate.
This family name is used as installation folder. You can't set it and if it changes you have to uninstall/install again manually and lose all your previous configurations.
We thought about leaving .appinstaller (and UWP) because of that (it will be extremely painfull to do it again at every changes of CA policies). It's pretty sad because the auto-update and remote installation functionalities are awesome!
One fix is to use a self-signed certificate (you can copy/paste the fields of the old certificate) but it feels unprofessional.

This problem could be solved if the "Family name" was editable or if, at least, there were an alternative "Family name", call it Custom, Legacy or Migration  that could be used solely for application updates, from one old Family name (due to the expiring certificate) to a new Family name (generated with the new certificate).
Right now renewing our signing-certificates is far from being painless for us, developers.

I have a different scenario with the same cause.  The package is made available via the Windows Store but also because of customers where store access is blocked also may obtain it directly from my website.  Obviously I can't  use the Microsoft Store cert when I distribute myself, so a customer that originally obtained the store version cannot upgrade.

We have had this issue the last week or so. Our problem was caused by the subject name having been changed on the re-issue of the certificate. Once we corrected this our issue was resolved.
We are deploying via a URL and appinstaller.

Any update on this?
We ran in this problem again, this time the CA removed street address and postal code.  (https://www.leaderssl.com/news/527-from-march-1-2021-sectigo-will-remove-street-address-and-postal-code-information-from-all-public-certificates)

I now have the issue in a way more common with all of you.  I have been through two different CAs (Sectigo and Digicert) and they both refuse to include the additional fields that were in my previous certificate.  Thus my customers cannot upgrade. and must manually uninstall / install.  The certificate should not cause package lineage to fail.  Either fix that or give us an additional field in the AppXManifest used to generate the PublisherId hash used in Package Family Name.

We introduced a new feature that is currently in an Insider Build that tackles the issue of packages unable to update due to signing certificate changes. Here is the link to the documentation: https://docs.microsoft.com/en-us/windows/msix/package/persistent-identity

Step 4 : Sign the catalog with the old certificate.  The old certificate has expired.  Is this process going to work?

You can find at the end of the article:

In order to leverage this feature, you will need to do this before the old certificate has expired.

It seems not

You will still need to install the old certificate (recommended with timestamp) on the machine for the platform to install the package that was signed by the new certificate.

Ours machines or customers?
It's currently in the Insider Build, but will it be available for currents versions of Windows (1909, 2004, 20H2, 21H1)?

Two years later and this issue is still making our lives miserable. Our certificate is near expiration again and we've just asked for a new one. This time (again) the CA has changed some fields and our new certificate (again) does not have the exact Subject information in it.
According to Persistent Identity documents seem incomplete (or feature is broken), and makeappx gives uninformative error message, "the device will need to have the old certificate in order to install the package and use this feature", meaning that we need a way to install the old (expiring) certificate in our users machines, in order for the "MSIX persistent identity" to work at all. This means not only for existing customers (for upgrading) but also for new installations (really???). At least that's what is implied after reading the 2nd consideration and the comment posted by @dianmsft in https://github.com/MicrosoftDocs/msix-docs/issues/304#issuecomment-1159260121 in the former issue.
Again, we are forced to follow the least friction path and ask our user's to manually uninstall the program, reboot and reinstall it again in order to keep on receiving updates. The workaround described in https://docs.microsoft.com/en-us/windows/msix/package/persistent-identity is completely useless as it is now (besides not being described in enough detail).

This is not an acceptable process.
CAs require certificate renewal every year so this process says I'd have to start building chains of expired certificates for the catalog.  In four years I'll be telling them, yeah just install these 4 expired certificates on all of your systems and then you can install this product.  And not only for the upgrade, but also a net-new company getting this software for the first time.
Neither for the software vendor, and certainly not for the customer.  There is no world in which I would advise the customer that they should install and rely upon an expired certificate.  So, I guess I'll be telling customers to uninstall and reinstall again this year.
I guess that being its own CA, Microsoft never has to deal with these issues.  But how are you going to move your partners to want to release as MSIX like this?

I understand that this process is awkward at best, so I want to offer some insight to at least explain some of it.
Ensuring that an update to an app comes from the same publisher is very important. If someone manages to take over the identity of an app in an update, they would have access to the app's data (like credentials stored in a Credential Locker) which isn't good. The way this is prevented is by ensuring that the app is signed by the same entity. The issue is that if the cert subject changes there is no easy way to be sure that the new and old certificates belong to the same entity. I know it is problematic for you to not be able to update your app in that case, but that same mechanism is what prevents an attacker from hijacking it.
What the Persistent Identity feature provides is a way for you to let the OS know that two different subjects refer to the same entity. If the cert subject changes from A to B, this is done by having an artifact stating "A is also called B" that is signed by A. Now, to be sure that the artifact is legit (and not faked by an attacker), the signature needs to be valid. That means that it was created before cert A expired, that the system trusts on cert A, and that the artifact is timestamped (if past the expiration).
If you have any suggestion of how to make it easier while still being secure, I can bring it to the team for consideration.

Here is a summary of my thoughts on this.

Code Signing of a package does not equal identity.  Code signing is only a promise that the package has not been touched since the signer signed it.  Loss of the certificate password (as is believed to have happened to one well-known vendor leading to attacks) means anything could be in code signed by the cert.
Customers should not equate code signed by a cert as being automatically safe in their security procedures.  Hashes, while not perfect, are the best thing we have.  Having a known hash of a package that you have verified does equal package identity. Customers interested in identifying software that is safe in security systems (such as App Locker or WDAG) should be using allowed software identified via hashes.
The most important job of a public CA is to ensure that they know the customer that they provide a certificate to is that customer.  The part of the certificate that uniquely identifies the certificate owner is contained in the Subject field, just not the entire field.  It is the “CN=” portion of that field.
Public CAs alone control the syntax provided in the subject field.  As a software vendor requesting a certificate from them, I provide a CSR that contains information that they will use to generate the certificate, but the software vendor has absolutely zero control over what that subject field will contain.  The public CAs that I work with have a standard that they implement, apparently through a software algorithm (because every CA employee I talk to tells me they have no control over what the output syntax will be).  These algorithms can change, and they have for me each of the last two years.  Furthermore, even though I purchased a 3-year certificate they issue it in only 1 year validity, and I must use a renewal process to get a valid certificate each year.  This renewal process will use the then current algorithm to generate the subject field.
•	Last year, the algorithm had changed to remove the “POSTAL=” field.  I was told that this was for my security, but since the rest of the address can be gleamed from the certificate I didn’t feel any more secure.
•	This year, the algorithm has changed to always include an “OU=”, and even if one is not provided in the CSR they just duplicate the “O=” field using it.
The idea that MSIX wants to use Persistent Identity of the software publisher is a good idea. It is the implementation of that idea that is deeply flawed.  By depending on the full subject field which is arbitrarily changing, there is no persistence.
It isn’t my role to tell you how to fix this.  The current process of using the current Persistent Identity implementation is leading to a change package identity due to the hash generated from the full subject field. This then leads to a different package identity each year, preventing the custom from having a smooth upgrade process.  The workaround that requires using expired certificates is a non-starter.

I don't know how you can fix this without breaking everything first, but something needs to be done or you will see many vendors staying with/returning to MSI deployments.

Oh, I left off one more thing.  Any persistent identity solution for the software publisher should also cover the scenario where the name of the publisher changes due to merger/acquisition.

@lechacon :

If you have any suggestion of how to make it easier while still being secure, I can bring it to the team for consideration.

Let's try and made up an scenario where we have a near-expiry certificate, let's call it Old-Cert, and another certificate New-Cert. Both certificates have an overlapping window where both are valid (the old one is not yet expired and the new one is already issued and valid). This is the only prerequisite for the procedure that is described below (an overlapping window).

Let's suppose we have a MSIX application that has been released for quite some time, always signed with the Old-Cert. In the next image these releases are Release A and any other release before that one, in red.
Now, we reach the point where a new version is required to be launched into market (Release B). This time we have both certificates available but the developer will still sign that release with the Old-Cert. Beside that, and here comes the interesting step, the public key of the New-Cert will also be signed (using private key of Old-Cert) timestamped, and included in Release B.
That public-key of New-Cert, being signed with the private-key of the Old-Cert is the only key-chain that the MSIX upgrade subsystem will need to ensure that, whenever a new release comes into play (Release C in the image) it will be a valid one: the new release will be valid if it still comes signed with the Old-Cert or by the New-Cert that was preapproved in an earlier release (Release B).
Finally, the time comes to launch Release C, that will be signed only with New-Cert. When the MSIX upgrade is launched, it will see that it is not signed with Old-Cert, but it is signed with the New-Cert which was preapproved in an earlier release, and will proceed and install the upgrade as normal (maybe it needs to change the target directory of the application, since the Family Name might probably change).
There is no need for a Persistent Identity as it was defined in https://docs.microsoft.com/en-us/windows/msix/package/persistent-identity. We only need a way to create a single-point-in-time continuity between two different certificates, and that can be ensured by simply signing the public-key of the new one with the private-key of the old one.
@TimMangan

Oh, I left off one more thing. Any persistent identity solution for the software publisher should also cover the scenario where the name of the publisher changes due to merger/acquisition.

I think this solution would work in your scenario too. It would not matter if any field in the New-Cert matches or not any in the Old-Cert, since the approval derives from the fact that the New-Cert was signed by the Old-Cert as a legit succesor of it.
The only drawback that I can think of this procedure is the case where some users seldomly used the application, they skipped Release B, and tried to update from Release A to Release C (without knowing of Release B because they didn't open the application during the time it was published). In that case the upgrade will fail, since they didn't go through Release B which set the foundations for the certificate upgrade. However, in order to minimise the chances of that scenario to happen, the developer could release several versions of the application (Release B1, Release B2, Release B3... during an extended overlapped window), all of them including the signed New-Cert, and approving it as a legit new certificate for any later release.
Any one sees any flaws in this procedure? Could it be implemented something like this in the MSIX upgrade subsystem?
Just my two cents (I hope they're worth more than that). Regards.

It is my understanding that a brand new customer receiving Release B or Release C will be required to install Old-Cert to be able to install the release.  This is not reasonable.  Nor is it reasonable to require me to release a "Release-B as upgrade" and separately "Release-B as new" in parallel.
Maybe the doc confused me about that requirement, but that is how I read it.

It is my understanding that a brand new customer receiving Release B or Release C will be required to install Old-Cert to be able to install the release. This is not reasonable. Nor is it reasonable to require me to release a "Release-B as upgrade" and separately "Release-B as new" in parallel.

I don't think that any brand-new users installing Release B would require anything particular to be installed. Release B would be signed with the still-valid Old-Cert, just as any other any earlier releases (Release A and previous ones).
On the other hand, brand-new users installing Release C directly, would never know there was a previous Old-Cert at all.
In no case, final users would need to install any certificates (expired or not) in their local machines. My request is that the MSIX upgrade subsystem should be modified to allow upgrades in the app whenever any of these two things happens:

The certificate signing the new release is exactly the same as the previous one, or...
The certificate signing the new release is a preapproved certificate (a different certificate that was previously signed with the old one). Of course, in order to do this check, the signed new certificate should  be stored somewhere; probably the registry or the app directory itself, but that would be left up to the implementation of the MSIX upgrade procedure itself. I no case any of the old nor new certificates should be installed in the certificate stores of the users' machines.

@TimMangan

Loss of the certificate password […] means anything could be in code signed by the cert.

I'm no expert in PKI, but I think that's what revocation is for.

Customers should not equate code signed by a cert as being automatically safe in their security procedures.

Yes, something being signed is no proof that it is safe. But if an app is signed by anybody but the publisher, that's a pretty good sign that somebody may be trying to impersonate the publisher and the app is not safe.

The part of the certificate that uniquely identifies the certificate owner is contained in the Subject field, just not the entire field. It is the “CN=” portion of that field.

I don't think that is true. For example, the names "CN=Jane Doe, C=US" and "CN=Jane Doe, C=UK" probably refer to different people.

using expired certificates is a non-starter.

Could you expand on why you think that?
The expired certificate is not used to sign anything new (not sure if any tool would even let you do that). Instead, it is used to sign the artifacts before it expires, and the timestamp proves that it was valid at the time of signing.

@jagbarcelo

Both certificates have an overlapping window where both are valid (the old one is not yet expired and the new one is already issued and valid). This is the only prerequisite for the procedure that is described below (an overlapping window).

That's more or less the same as for the existing feature :)

the public key of the New-Cert will also be signed (using private key of Old-Cert)

This part is basically what the Persistent Identity feature does. Only that instead of endorsing the key/cert, we endorse the cert subject; and the artifact goes in new version instead of the old one. That way, if you re-new your certificate again and are able to preserve the new subject name, the same artifact would still work.

Now, we reach the point where a new version is required to be launched into market (Release B). This time we have both certificates available but the developer will still sign that release with the Old-Cert.

This is only possible if the release schedule lines up with having both certs. With the current feature, you can generate the signed artifact during this time window, then sit on it until you are ready to publish a new release and include the artifact in it even if the overlapping window is now long gone.

The only drawback that I can think of this procedure is the case where some users seldomly used the application, they skipped Release B, and tried to update from Release A to Release C (without knowing of Release B because they didn't open the application during the time it was published).

I see that as a pretty big drawback. The feature as it is now was designed so that upgrading would work between any two versions, regardless of how many you skip.

the developer could release several versions of the application […], all of them including the signed New-Cert, and approving it as a legit new certificate for any later release.

I'd expect that to not be possible in most cases due to the overlapping window being too small to fit more than one release. For example, with an app released twice a year with a cert expiration of 1 year, you would only be able to use the same cert for two releases, and the overlapping window will be even less than that.

since the Family Name might probably change.

Yes, it would change as it is derived from the package name and the publisher name (which matches the cert subject). Which is a problem as it is supposed to identify a package across versions and it is used in different places. For example, the Shared Package definition uses it and Package Dependencies are defined in terms of Name + Publisher.

@dianmsft, @TimMangan I also tried the process described in https://docs.microsoft.com/en-us/windows/msix/package/persistent-identity but got stuck in the Create the package section. We are using Visual Studio too but the documentation was so lean and short that we couldn't find a way to pass that stage.
Then I ask for more information about it to the guys who made that documentation (see https://github.com/MicrosoftDocs/msix-docs/issues/333) and they replied:

This feature is currently not supported for Visual Studio. But we'll consider it in our backlog

... and back to square one... (sigh)

"You will still need to install the old certificate (recommended with timestamp) on the machine for the platform to install the package that was signed by the new certificate" in the document is being mis-understood by us and that the expired certificate does not need to be installed on end user systems.

@TimMangan It should not work without the expired certificate(*); and if it does that's a bug. If the signature is not trusted, then there isn't much difference with it not being signed as anybody could create a fake certificate and use it to sign.
(*) It can be any certificate in the certificate chain, it doesn't need to be yours specifically. For example, it can be the one from the CA root, which could still be valid.

The question becomes how to trick WAP Publishing in Visual Studio to include the /pb option when makemsix is run? Is there an underdocumented element to include in the WAP project xml Property Group?

@TimMangan @jagbarcelo
Unfortunately, VS hasn't been updated to support this feature yet. Even if you are able to make VS pass the /pb option to makeappx, you will likely need to sign manually with signtool as VS would probably enforce that the manifest publisher must be the same as the cert subject.
I think a flow like this would work:

Build the package with VS but don't sign. This would produce the AppxManifest.xml from the Package.appxmanifest, place all the files in the correct location and other things like that.
Edit the package manually to add the artifacts and sign. This could probably be done in a postbuild task
2.1 Unpack with makeappx unpack
2.2 Re-pack with makeappx pack but passing the /pb option
2.3 Sign with signtool

Or if you can get VS to pass the /pb option you would be able to do

Build with VS with /pb but don't sign
Sign with signtool (in a postbuild task)

Windows Application Packaging projects are not my area of expertise, so the following may actually be very a bad idea and not officially supported but....
To make VS pass /pb, you could look into the Microsoft.AppxPackage.Targets file to try and find a property that you could set that would be passed to makeappx. On my machine this is on D:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Microsoft\VisualStudio\v17.0\AppxPackage\Microsoft.AppxPackage.Targets. In there I saw that the <MakeAppxPackage> task takes as input Parameters="$(CreatePackageMakeAppxParameters)". So it may be that you can set <CreatePackageMakeAppxParameters>/pb artifacts.txt</CreatePackageMakeAppxParameters> in your .wapproj file.

To make VS pass /pb, you could look into the Microsoft.AppxPackage.Targets file to try and find a property that you could set that would be passed to makeappx. On my machine this is on D:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Microsoft\VisualStudio\v17.0\AppxPackage\Microsoft.AppxPackage.Targets. In there I saw that the <MakeAppxPackage> task takes as input Parameters="$(CreatePackageMakeAppxParameters)". So it may be that you can set <CreatePackageMakeAppxParameters>/pb artifacts.txt</CreatePackageMakeAppxParameters> in your .wapproj file.

No luck with that. When we included <CreatePackageMakeAppxParameters>/pb artifacts.txt</CreatePackageMakeAppxParameters> within our PackageProject.wapproj file and tried to Publish, we receive this error:

It seems Visual Studio 2022 (Community at least) does not support the /pb option, not even when passed manually inside the .wapproj file.
I'm starting to lose all hope that this issue would ever be solved for real-world usable scenarios in a simple way, instead of a twisted cumbersome tweak using commands that cannot be reproduced/scripted/integrated in Visual Studio which is what we use.
We are forced to follow the least friction path and ask our users to uninstall, reboot and reinstall the app again.

Unknown command line option: "/pb"

That probably means that the version of makeappx you are using does not support this feature. It is available starting on build 22000. I imagine that VS uses an SDK with version matching your project's target platform, so if you are targeting something older than build 22000, you won't be able to use it.

We introduced a new feature that is currently in an Insider Build that tackles the issue of packages unable to update due to signing certificate changes. Here is the link to the documentation: https://docs.microsoft.com/en-us/windows/msix/package/persistent-identity

From this document:

Starting in Windows Insider Preview Build 22000, an artifact will need to be created to show the relationship between the old certificate and the new certificate that is being used for signing.

@dianmsft @lechacon Does that mean we have to use the Windows 11 SDK or does that mean this feature is only supported on Windows 11? (The requirements section specifies only the SDK, but it's not clear to us)
Just to document our problems here too:

CA change lead to different CN
Legal business name change lead to different CN
Changes in CA requirements lead to different CN

For anyone looking for the same (see the above question about requirements), I found an answer in the docs repo.
Thanks @marv51 for testing this!
TL;DR

It is definitely a runtime requirement. This publisher-bridge does not work on Windows 10 at all.

I'm just starting with code-signing and wondering if this is still an issue.

@florelis We've been looking into this feature a bit more now, but it appears to be hard to use for a few interacting reasons (beyond the VS Studio issues which don't affect us because we don't use the native toolchain at all).
The problem is the decision to stop maintaining Windows 10. That's still most of the market share and given current trends, it will be many years until Windows 11 is the main version in use let alone having replaced 10.
That means that using the publisher bridge effectively forks the packaging. From that moment on you need a separate MSIX+appinstaller update stream for Win10 vs Win11. The Win11 one must continue to express the old app identity and be signed with the new cert, but therefore can't be installed on Win10. The Win10 MSIX must be signed under the new non-expired identity, therefore it can't be used to upgrade anything. Users must uninstall and reinstall. Also users must be given the right package at install time depending on their OS version, and any code that relies on or uses the package identity needs to handle the fact that there may be >1 identity in use for the same app.
This generates enormous logistical complexity. Multiple sets of "independent" MSIX packages with their own update streams, needing to keep them separated, etc.
Now, if Win10 got backports of this feature the problems mostly go away. We could potentially detect users are not fully updated and tell them to apply OS updates in order to re-enable app updates. That's harder when the upgrade we're asking the user to apply is Win11, which isn't even available to all users. But we know from bitter experience that the MSIX team seem either to be prevented by internal rules or uninterested in maintaining the technology for Win10. Whatever the reason, Win10 has to be taken as fixed just as if it were shipped on a CD.
That constraint means we'll probably need to look at alternatives to the publisher bridge, like just forcing an uninstall+reinstall cycle any time the CN has changed. And longer term, look into moving away from MSIX (somehow - it's not like there are great alternatives). It has some wonderful features but the state of the tech in Win10 just isn't good enough, yet Win10 is the OS that matters most.
I realize you're a dev and don't directly influence these decisions but please do send this feedback up the chain. Package identity is a key part of the Windows platform strategy but devs can't adopt it when a basic part of the story doesn't work on Win10.

The Persistent Identity doc states that:

You can create several artifacts, however the platform currently supports up to 5.

Does that mean that, as time passes and the publisher CN changes, newer versions of the package should include artifacts passing the buck to each subsequent change? That is, one artifact for Publisher1->Publisher2, another for Publisher2->Publisher3, etc. And after the package has accumulated 5 of those changes, it is no longer possible to maintain the chain for updates to keep working if there are further publisher changes?
On the flip side, 5 publisher changes would likely take several years, by which time hopefully a more permanent solution is found.
But unless the Persistent Identity feature gets backported to Win 10, it doesn't help us that much.

@mikehearn
Thank you for your feedback. I'm not currently as involved in MSIX, but I've forwarded your feedback to the appropriate team.
@leo-hydraulic

Does that mean that, as time passes and the publisher CN changes, newer versions of the package should include artifacts passing the buck to each subsequent change? That is, one artifact for Publisher1->Publisher2, another for Publisher2->Publisher3, etc. And after the package has accumulated 5 of those changes, it is no longer possible to maintain the chain for updates to keep working if there are further publisher changes?

Yes, that is correct.

Is this ever going to be resolved?

We implemented an alternative approach in Hydraulic Conveyor, a packaging tool that can make MSIX files. It detects if the signing identity has changed and if so, forces an uninstall/reinstall cycle on app startup.
https://conveyor.hydraulic.dev/11.0/configs/escape-hatch/
Although mostly targeted at cross-platform app developers, you can use Conveyor to make MSIX files and appinstaller update streams that are only for Windows as well. Conveyor works around bugs in MSIX and Windows 10 to provide more reliable installs and updates, and also supports forcing synchronous updates on app startup,.
I hope we can help people who need a better MSIX experience here!

MS, this is still relevant and creates a lot of unnecessary frustration.

Why change to the publisher change the unique  id for the application ?
Why not use PackageName for installation/updates ? instead of PackageFamilyName that changes when cert changes ?
Why there is a different behaviour on windows 10 and 11 ? if you install application with same PackageName but different PackageFamilyName on windows 11 new package will install fine and bot will run at the same time, on window 10 new package will not install at all and there will be error message "Windows cannot install package  because a different package  with the same name is already installed."


How to use the gripper in python

Hello,
I want to use the gripper in python. I follow the franka ros tutorial and I get that command to use the gripper:
rostopic pub --once /franka_gripper/grasp/goal              franka_gripper/GraspActionGoal              "goal: { width: 0.022, epsilon:{ inner: 0.005, outer: 0.005 }, speed: 0.1, force: 5.0}"
Is there a moveit message to command the gripper ?
I doesn't find any python example for that.

The grasping is a ros action. You have to look at the ros action tutorials. For your convenience, I took the example from there and adapted it for the grasping message:
#! /usr/bin/env python3
import franka_gripper.msg
import rospy
import sys

# Brings in the SimpleActionClient
import actionlib

# Brings in the messages used by the grasp action, including the
# goal message and the result message.

def grasp_client():
    # Creates the SimpleActionClient, passing the type of the action
    # (GraspAction) to the constructor.
    client = actionlib.SimpleActionClient('/franka_gripper/grasp', franka_gripper.msg.GraspAction)

    # Waits until the action server has started up and started
    # listening for goals.
    client.wait_for_server()

    # Creates a goal to send to the action server.
    goal = franka_gripper.msg.GraspGoal()
    goal.width = 0.022
    goal.epsilon.inner = 0.005
    goal.epsilon.outer = 0.005
    goal.speed = 0.1
    goal.force = 5

    # Sends the goal to the action server.
    client.send_goal(goal)

    # Waits for the server to finish performing the action.
    client.wait_for_result()

    # Prints out the result of executing the action
    return client.get_result()  # A GraspResult

if __name__ == '__main__':
    try:
        # Initializes a rospy node so that the SimpleActionClient can
        # publish and subscribe over ROS.
        rospy.init_node('grasp_client_py')
        result = grasp_client()
        print("Success: ",result.success)
        print("Error message: ", result.error)
    except rospy.ROSInterruptException:
        print("program interrupted before completion", file=sys.stderr)

Thank you !

Hello,
I am working on project, connected with this gripper. Thanks for the code above, it helped to understand many thing. Unfortunately, when I run it, I receive an error:
ModuleNotFoundError: No module named 'franka_gripper'

However, import franka_gripper.msg is added like in the code, discussed in this question.....

you need to source ros and if you compile franka_ros yourself you also need to source the setup.bash in your devel folder

It worked. Thank you so much!
P.S. There were some problems with my system, but you've set me on the right path

The grasping is a ros action. You have to look at the ros action tutorials. For your convenience, I took the example from there and adapted it for the grasping message:
#! /usr/bin/env python3
import franka_gripper.msg
import rospy
import sys

# Brings in the SimpleActionClient
import actionlib

# Brings in the messages used by the grasp action, including the
# goal message and the result message.

def grasp_client():
    # Creates the SimpleActionClient, passing the type of the action
    # (GraspAction) to the constructor.
    client = actionlib.SimpleActionClient('/franka_gripper/grasp', franka_gripper.msg.GraspAction)

    # Waits until the action server has started up and started
    # listening for goals.
    client.wait_for_server()

    # Creates a goal to send to the action server.
    goal = franka_gripper.msg.GraspGoal()
    goal.width = 0.022
    goal.epsilon.inner = 0.005
    goal.epsilon.outer = 0.005
    goal.speed = 0.1
    goal.force = 5

    # Sends the goal to the action server.
    client.send_goal(goal)

    # Waits for the server to finish performing the action.
    client.wait_for_result()

    # Prints out the result of executing the action
    return client.get_result()  # A GraspResult

if __name__ == '__main__':
    try:
        # Initializes a rospy node so that the SimpleActionClient can
        # publish and subscribe over ROS.
        rospy.init_node('grasp_client_py')
        result = grasp_client()
        print("Success: ",result.success)
        print("Error message: ", result.error)
    except rospy.ROSInterruptException:
        print("program interrupted before completion", file=sys.stderr)

Does this code expect you to also execute a server starting call somewhere?


application tag naming hot fix

My bad)

No worries, I also missed it when I reviewed it and merged it.


Port redux project async example to ng-redux

@wbuchwalter thank you for creating this library! I believe redux can help with some pain points I'm experiencing with a large Angular application.
Initially I had a hard time wrapping my head around how to create async action creators using $http or $resource and couldn't find an example, so I ported https://github.com/rackt/redux/tree/master/examples/async to ng-redux. Here's the resulting code if anyone else finds it helpful. I tried to maintain the coding style used in the counter example. Lastly, hopefully the webpack config isn't too wonky -- I'm more familiar with browserify.

Hey Evan!
Thanks for the cool PR, I'll review it soon.
Regarding async, there is quite a few way to achieve that:

Using thunk middleware like you did there
Using $httpor similar, with dependency injected middlewares (an example can be found here)
Using promise middleware or similar, e.g: redux-promise-middleware
And probably many others...


cobra cannot be installed with python=3.9

[ ] I read the conda-forge documentation and could not find the solution for my problem there.

Hello,
The cobra package cannot be installed with python=3.9 (but it works for python 3.6, 3.7 and 3.8). In the other hand, the conda package from the bioconda channel works. The issue has been spotted on both Linux (Ubuntu 20.04) and macOS).
conda create -c conda-forge -n test python=3.9
conda install -c conda-forge -n test cobra
# waiting a long time

After a some time, conda install report issue of dependancies:
Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: |
Found conflicts! Looking for incompatible packages.
This can take several minutes.  Press CTRL-C to abort.
failed

UnsatisfiableError: The following specifications were found to be incompatible with each other:

Output in format: Requested package -> Available versions

Using mamba, the issue is more clear:
conda install -c conda-forge -n test mamba
conda activate test
mamba install -c conda-forge cobra

The issue here:
Looking for: ['cobra']

brsynth/noarch           [====================] (00m:00s) Done
brsynth/osx-64           [====================] (00m:00s) Done
pkgs/r/noarch            [====================] (00m:00s) Done
pkgs/r/osx-64            [====================] (00m:00s) Done
pkgs/main/noarch         [====================] (00m:00s) Done
pkgs/main/osx-64         [====================] (00m:01s) Done
conda-forge/noarch       [====================] (00m:01s) Done
conda-forge/osx-64       [====================] (00m:05s) Done
Encountered problems while solving:
  - package cobra-0.21.0-pyhd8ed1ab_0 requires rich <7.0, but none of the providers can be installed

Environment (conda list):
$ conda list
# Name                    Version                   Build  Channel
brotlipy                  0.7.0           py39hcbf5805_1001    conda-forge
bzip2                     1.0.8                h0d85af4_4    conda-forge
c-ares                    1.17.1               h0d85af4_1    conda-forge
ca-certificates           2020.12.5            h033912b_0    conda-forge
certifi                   2020.12.5        py39h6e9494a_1    conda-forge
cffi                      1.14.5           py39h319c39b_0    conda-forge
chardet                   4.0.0            py39h6e9494a_1    conda-forge
conda                     4.10.1           py39h6e9494a_0    conda-forge
conda-package-handling    1.7.3            py39h89e85a6_0    conda-forge
cryptography              3.4.7            py39ha2c9959_0    conda-forge
icu                       68.1                 h74dc148_0    conda-forge
idna                      2.10               pyh9f0ad1d_0    conda-forge
krb5                      1.17.2               h60d9502_0    conda-forge
libarchive                3.5.1                h0a5793d_1    conda-forge
libcurl                   7.76.1               h8ef9fac_1    conda-forge
libcxx                    11.1.0               habf9029_0    conda-forge
libedit                   3.1.20191231         h0678c8f_2    conda-forge
libev                     4.33                 haf1e3a3_1    conda-forge
libffi                    3.3                  h046ec9c_2    conda-forge
libiconv                  1.16                 haf1e3a3_0    conda-forge
libnghttp2                1.43.0               h07e645a_0    conda-forge
libsolv                   0.7.18               hcf210ce_0    conda-forge
libssh2                   1.9.0                h52ee1ee_6    conda-forge
libxml2                   2.9.10               h93ec3fd_4    conda-forge
lz4-c                     1.9.3                h046ec9c_0    conda-forge
lzo                       2.10              haf1e3a3_1000    conda-forge
mamba                     0.11.3           py39hb671511_0    conda-forge
ncurses                   6.2                  h2e338ed_4    conda-forge
openssl                   1.1.1k               h0d85af4_0    conda-forge
pip                       21.1               pyhd8ed1ab_0    conda-forge
pycosat                   0.6.3           py39hcbf5805_1006    conda-forge
pycparser                 2.20               pyh9f0ad1d_2    conda-forge
pyopenssl                 20.0.1             pyhd8ed1ab_0    conda-forge
pysocks                   1.7.1            py39h6e9494a_3    conda-forge
python                    3.9.2           h2502468_0_cpython    conda-forge
python_abi                3.9                      1_cp39    conda-forge
readline                  8.1                  h05e3726_0    conda-forge
reproc                    14.2.1               hbcb3906_0    conda-forge
reproc-cpp                14.2.1               h2e338ed_0    conda-forge
requests                  2.25.1             pyhd3deb0d_0    conda-forge
ruamel_yaml               0.15.80         py39h4b0b724_1004    conda-forge
setuptools                49.6.0           py39h6e9494a_3    conda-forge
six                       1.15.0             pyh9f0ad1d_0    conda-forge
sqlite                    3.35.5               h44b9ce1_0    conda-forge
tk                        8.6.10               h0419947_1    conda-forge
tqdm                      4.60.0             pyhd8ed1ab_0    conda-forge
tzdata                    2021a                he74cb21_0    conda-forge
urllib3                   1.26.4             pyhd8ed1ab_0    conda-forge
wheel                     0.36.2             pyhd3deb0d_0    conda-forge
xz                        5.2.5                haf1e3a3_1    conda-forge
yaml                      0.2.5                haf1e3a3_0    conda-forge
zlib                      1.2.11            h7795811_1010    conda-forge
zstd                      1.4.9                h582d3a0_0    conda-forge

Best wishes,

Thank you for the report. I will make a new release of cobrapy this week that among other things, will lift some of the stricter version pinning.

Great!

I've just tried this in a conda environment with Python 3.9 and everything seems to be in order.


Build fails in PhoneGap build

iOS build fails on build.phonegap.com, log output attached.
build.zip

Yeah, it seems PhoneGap build still does not support Swift, see this issue.
As cordova-plugin-photo-library implemented in Swift, the only way around it is to wait PhoneGap to support Swift, sorry.


SpringDecoder should respect 'decode404' settings

'decode404' is not clearly defined, but I think that for response 404, Feign client should return Optional.empty() or null.
Optional case is implemented correctly, but second case was wrong - SpringDecoder tried construct object basing on response body instead just return null.

After a discussion, the team has decided not to introduce this change.


Android 11 (API 30): request(PERMISSIONS.ANDROID.ACCESS_BACKGROUND_LOCATION) never returns blocked

Bug summary
In my app I run the following code
await requestMultiple([PERMISSIONS.ANDROID.ACCESS_FINE_LOCATION, PERMISSIONS.ANDROID.ACCESS_COARSE_LOCATION])
const status = await request(PERMISSIONS.ANDROID.ACCESS_BACKGROUND_LOCATION)
console.log({ status })

If by the third time the user denies the permission, it doesn't show the popup anymore (which is expected behavior), but it always returns denied, never blocked.
I am handling this by locally counting the number of attemps, but it would be nice if this were fixed or something told me what I did wrong. 🙏
Library version
3.7.2
Environment info
System:
    OS: macOS 13.3.1
    CPU: (8) arm64 Apple M1
    Memory: 52.34 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.15.0 - ~/.nvm/versions/node/v18.15.0/bin/node
    Yarn: 3.5.1 - ~/.nvm/versions/node/v18.15.0/bin/yarn
    npm: 9.6.6 - ~/.nvm/versions/node/v18.15.0/bin/npm
    Watchman: 2<IP_ADDRESS> - /opt/homebrew/bin/watchman
  Managers:
    CocoaPods: 1.12.1 - /Users/ren/.rvm/gems/ruby-2.7.6/bin/pod
  SDKs:
    iOS SDK:
      Platforms: DriverKit 22.4, iOS 16.4, macOS 13.3, tvOS 16.4, watchOS 9.4
    Android SDK:
      Android NDK: 22.1.7171670
  IDEs:
    Android Studio: 2022.1 AI-221.6008.13.2211.9619390
    Xcode: 14.3/14E222b - /usr/bin/xcodebuild
  Languages:
    Java: 11.0.13 - /usr/bin/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: 18.1.0 => 18.1.0
    react-native: 0.70.9 => 0.70.9
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

Steps to reproduce

Write this, in some function:

await requestMultiple([PERMISSIONS.ANDROID.ACCESS_FINE_LOCATION, PERMISSIONS.ANDROID.ACCESS_COARSE_LOCATION])
const status = await request(PERMISSIONS.ANDROID.ACCESS_BACKGROUND_LOCATION)
console.log({ status })

give that function to a button.
click the button 3 times and deny them all.
See how the status is always denied.
keep clicking.
status is still denied.

Reproducible sample code
await requestMultiple([PERMISSIONS.ANDROID.ACCESS_FINE_LOCATION, PERMISSIONS.ANDROID.ACCESS_COARSE_LOCATION])
const status = await request(PERMISSIONS.ANDROID.ACCESS_BACKGROUND_LOCATION)
console.log({ status })

@rarenatoe Hi, this is unfortunately not a place to get help, but to declare issues with the library. For that, please be sure that it always occurs (by providing a minimal reproduction repository).
You can also check the example app: if it doesn't occur with, that's mean the issue might came from something else.

PS: ACCESS_BACKGROUND_LOCATION MUST be requested with ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION (documentation)
This means that your reproducible code:
await requestMultiple([PERMISSIONS.ANDROID.ACCESS_FINE_LOCATION, PERMISSIONS.ANDROID.ACCESS_COARSE_LOCATION])
const status = await request(PERMISSIONS.ANDROID.ACCESS_BACKGROUND_LOCATION)
console.log({ status })

Should be:
const status = await requestMultiple([PERMISSIONS.ANDROID.ACCESS_FINE_LOCATION, PERMISSIONS.ANDROID.ACCESS_COARSE_LOCATION])
console.log({ status })

PS: ACCESS_BACKGROUND_LOCATION MUST be requested with ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION (documentation)
Replace your sample code with:
const requestedLocation = async () => {
  const status = await requestMultiple([
    PERMISSIONS.ANDROID.ACCESS_BACKGROUND_LOCATION,
    PERMISSIONS.ANDROID.ACCESS_FINE_LOCATION, // or ACCESS_COARSE_LOCATION
  ]);

  console.log({ status });
  return status;
};

Should do the trick.

@zoontek what you proposed just doesn't show the popup.
Seems like starting on API Level 30, foreground/background requests have to be made distinctly.


Make envFromSecret as a list - Grafana

https://github.com/grafana/grafana/issues/13682

/assign unguiculus


Auth proxies functionality

Add the possibility to pass flows via akto through an authenticated http proxy.

Hi @Thauza - this has been taken up. @mayankesh-akto is working on it.
You reported this issue a long ago, but is it possible to get more details on your requested functionality?


[Hot Fix][Template-X] Template x holiday blade

Bring back Template-X Holiday and the text layout
Resolves: https://jira.corp.adobe.com/browse/MWPW-140484?filter=381833
Test URLs:

Before: https://stage--express--adobecom.hlx.page/drafts/casey/template-x/holiday-collab?lighthouse=on
After: https://template-x-holiday-blade--express--adobecom.hlx.page/drafts/casey/template-x/holiday-collab?lighthouse=on

Codecov Report
Attention: 215 lines in your changes are missing coverage. Please review.

Comparison is base (508baf0) 31.72% compared to head (2ebd698) 31.99%.
Report is 4 commits behind head on main.

Files
Patch %
Lines

express/scripts/utils.js
16.48%
76 Missing :warning:

...locks/multifunction-button/multifunction-button.js
4.25%
45 Missing :warning:

express/blocks/shared/floating-cta.js
28.57%
35 Missing :warning:

express/blocks/template-list/breadcrumbs.js
4.54%
21 Missing :warning:

express/scripts/mobile-beta-gating.js
88.46%
12 Missing :warning:

express/blocks/template-x/template-x.js
0.00%
7 Missing :warning:

express/blocks/search-marquee/search-marquee.js
0.00%
6 Missing :warning:

express/blocks/shared/carousel.js
87.09%
4 Missing :warning:

express/blocks/template-list/template-list.js
0.00%
4 Missing :warning:

...cks/how-to-steps-carousel/how-to-steps-carousel.js
75.00%
3 Missing :warning:

... and 2 more

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #534      +/-   ##
==========================================
+ Coverage   31.72%   31.99%   +0.27%
==========================================
  Files         125      125
  Lines       23913    23995      +82
==========================================
+ Hits         7586     7677      +91
+ Misses      16327    16318       -9

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


Support Keras SeperableConv2d

Cannot visualize a model with sepConv2d

Can you share the model file?

If you just use a simple conv2d mode with seperable conv layers it doesnt work. Any basic one will do.

Can you share a model file or exact steps to reproduce the issue?

inpp = layers.Input((28,28,3))
x = layers.SeparableConv2D(32,3)(inpp)
x = layers.Flatten()(x)
x = layers.Dense(24)(x)

model = models.Model(inpp,x)
model.save('netron_model.model')
netron.start('netron_model.model',port=8585)

Thanks for your help by the way.

.model is CTNK or MXNet Model Server format. Keras files should have an .h5 extension for HDF5 format.

PERFECT. I see even though the file is saved as  .h5 .model breaks it. This is great thank you!


DELIA-44142: wpeframework crash from WifiManager plugin getSignalData()

Reason for change: wpeframework crash from WifiManager plugin getSignalData()
Test Procedure: Build and test based on README.md
Risks: Low
Signed-off-by: Mariusz Strozynski<EMAIL_ADDRESS>(cherry picked from commit 91c4dc44d69e5f9d7819330b66476d35c19d2309)

https://jenkins.code.rdkcentral.com/job/github-triggered/3026/ started

https://jenkins.code.rdkcentral.com/job/build-component-rdk-next/20016/ started.

Smoke tests for ['build-rpi-hybrid-refapp-rdk-next'] added.
https://jenkins.cmf.code.rdkcentral.com/job/test-components-flow/61018/

Smoke tests for ['build-qemux86-hyb-rdk-next'/'build-qemux86-mc-rdk-next'] added.
https://jenkins.cmf.code.rdkcentral.com/job/test-components-flow/61017/

Smoke tests for ['build-rpi-hybrid-wpe-rdk-next'/'build-rpi-mc-wpe-rdk-next'] added.
https://jenkins.cmf.code.rdkcentral.com/job/test-components-flow/61019/

Smoke tests for ['build-rpi-hybrid-thunder-rdk-next'] added.
https://jenkins.cmf.code.rdkcentral.com/job/test-components-flow/61020/

'['build-rpi-hybrid-thunder-rdk-next']' Smoke test FAILURE, investigation pending.
Flash Thunder [SUCCESS]
Thunder - Video Test [FAILURE]
RDKV Thunder Baeble Music App test [FAILURE]
https://jenkins.cmf.code.rdkcentral.com/job/test-raspberrypi-thunder-flow/6288/


No Python files found under the given path(s)

Despite many Python files existing in subdirectories of the current directory, none are found.
$ ruff --version
ruff 0.0.282

$ ruff --isolated .
warning: No Python files found under the given path(s)

$ ls bin/
monophony.py

$ bat pyproject.toml
───────┬───────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ [tool.ruff]
   2   │ builtins = ['_']
   3   │ extend-ignore = ['E4', 'E74', 'E722']
   4   │ extend-select = ['ARG', 'Q']
   5   │ #tab_size = 4
   6   │
   7   │ [tool.ruff.flake8-quotes]
   8   │ inline-quotes = 'single'
   9   │ docstring-quotes = 'single'
  10   │ multiline-quotes = 'single'
───────┴───────────────────────────────────────────────────────────────────────────────────────────────────

Is bin in a .gitignore, perhaps? Can you run with --verbose?

Is bin in a .gitignore, perhaps? Can you run with --verbose?

I got it. It's going all the way up to the .gitignore I have in my home directory and using that instead of the local one.
...
from: Some("/home/z/.gitignore"), original: "*"
...

To clarify, my home directory is a git repository, and all my projects have their own repositories inside it. None of the tools I use have any issues with this setup. Ruff also used to work fine until now.

Is there a .gitignore in the local directory too? Perhaps related to https://github.com/astral-sh/ruff/pull/5937, but not sure.

(This sounds like a bug, but I need to find time to reproduce locally before I can debug.)

I was able to reproduce! It looks like this is identical to https://github.com/BurntSushi/ripgrep/issues/2447. FWIW the workarounds mentioned in that issue did work for me.
@BurntSushi -- do you know if there's any way to avoid traversing past the "current" Git repository when enforcing .gitignore behavior in the ignore crate? (If not, I'm gonna close and suggest those workarounds as it's out of our control.)

The specific case of nested git repositories should be handled correctly. Or at least, the ignore crate attempts to do so. Perhaps there is a bug there. A specific repro would be helpful in that case.
But this doesn't apply to .ignore or .rgignore files, only .gitignore. For .ignore and .rgignore, there is no way to avoid traversing a certain point.

Okay cool, thanks. I'll put together a specific repro (both to confirm and facilitate debugging).

If I clone this, then run cargo run:
❯ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/ignore_crate_repro`
./python
./python/baz.py
./python/bar.py

However, if I add a .gitignore to the parent directory, which is a Git repo, with:
baz.py

And then run cargo run:
❯ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/ignore_crate_repro`
./python
./python/bar.py

Alternatively, if the parent directory isn't a Git repo, you can set apply this to get the same behavior:
diff --git a/src/main.rs b/src/main.rs
index 012362f..5e4dbe4 100644
--- a/src/main.rs
+++ b/src/main.rs
@@ -1,7 +1,7 @@
 use ignore::WalkBuilder;

 fn main() {
-    for result in WalkBuilder::new("./python").build() {
+    for result in WalkBuilder::new("./python").require_git(false).build() {
         match result {
             Ok(entry) => println!("{}", entry.path().display()),
             Err(err) => println!("ERROR: {}", err),

Interestingly, I can't reproduce it:
$ cd /tmp
$ git clone https://github.com/charliermarsh/ignore_crate_repro
$ cd ignore_crate_repro
$ cargo run
./python
./python/baz.py
./python/bar.py
$ echo baz.py > /tmp/.gitignore
$ cat /tmp/.gitignore
baz.py
$ cargo run
./python
./python/baz.py
./python/bar.py

And note that ripgrep handles this correctly too:
$ rg --files
Cargo.lock
Cargo.toml
LICENSE
pyproject.toml
python/bar.py
python/baz.py
src/main.rs

And if I change the parent .gitignore to a .ignore, then it is respected (as expected):
$ mv /tmp/.gitignore /tmp/.ignore
$ cargo run
./python
./python/bar.py

Or wait, okay, I missed that you said the parent directory is also a git repo. /tmp is not a git repo, so let's try that:
$ cd /tmp
$ rm -rf ignore_crate_repro/
$ rm .ignore
$ mkdir parentrepo && cd parentrepo
$ git init
Initialized empty Git repository in /tmp/parentrepo/.git/
$ touch dummy
$ git add dummy && git commit -m "dummy commit"
$ git clone https://github.com/charliermarsh/ignore_crate_repro
$ cd ignore_crate_repro
$ cargo run
./python
./python/baz.py
./python/bar.py
$ echo baz.py > ../.gitignore
$ cat ../.gitignore
baz.py
$ cargo run
./python
./python/baz.py
./python/bar.py
$ rg --files
Cargo.lock
Cargo.toml
LICENSE
pyproject.toml
python/bar.py
python/baz.py
src/main.rs

So all still seems well to me? I wouldn't expect the parent directory being a git repo to matter here because the parent traversal logic should stop right after it sees a git repo, which in this case is the current working directory.
And yeah, when require_git is disabled, then ignore specifically doesn't care about whether a git repo exists or not. It just blindly applies .gitignore filtering.

Ahh okay, I see. So this is partially my fault, apologies. Without require_git(false), it turns out I'm only seeing this when .gitignore is in my root directory, and I noticed that I have this in my ~/.gitconfig:
[user]
    name = Charlie Marsh
    email =<EMAIL_ADDRESS>[core]
    excludesfile = ~/.gitignore

Removing the excludesfile = ~/.gitignore fixes the issue for me (when not adding require_git(false)).
So I'm guessing that this behavior in Ruff stems from us setting require_git(false), which was done to fix https://github.com/astral-sh/ruff/issues/5930. I may just have to revert that, if this is the expected behavior (which it sounds like it is).

Yeah it sounds like expected behavior to me. Note that ripgrep exposes the require_git option as a --no-require-git flag. Some people really want ripgrep to not care about .git and some do. IIRC, ripgrep originally didn't care, but the VS Code folks convinced me to switch over to caring about whether to respect .gitignore based on whether .git was there or not. (I may be mis-remembering, this was a while ago.)


Goldmine Problem

Problem Link
https://www.geeksforgeeks.org/gold-mine-problem/
Coding platform
GeeksforGeeks
Programming language

[ ] C
[ ] C++
[ ] Java
[ ] Python

Additional context (OPTIONAL)
Add any other context or screenshots about the feature request here.

Please review this problem and assign me in Java.

I would like to work on this issue in C++.

I will do it in python.


[Pages and Navigation]: #450 Adds Nav bar, renders data in the pages

This PR does the following:

Sets up the three main pages (upcoming, overdue and completed).
Renders the deadline data from the store in the deadline cards.
Sets up a Nav bar  with components.

What we're still working on:

Filtering the data in the pages accordingly.
Finishing touches to the Nav bar
Finishing touches to the deadline card yet to be completed by the team working on it.

@a11rew

Ok


Using Custom Distance

Hello,
I wanted to perform NN search on a dataset of genomes. For this task, the distance between 2 datapoints is calculated by a custom script? I looked at the documentation and sort of understood how to incorporate my distance but I have a doubts -

The data is a bunch of filenames that I use to run a script that generates the distance. How should I use this data with pynndescent.NNDescent()? Entering a list of strings obviously won't work but using a dictionary wouldn't be supported if I am not wrong.

I'm afraid that at the moment you really need a 2D vector(ish) representation of data for this library to work. I do have some plans to hopefully one day extend it to allow more custom things, but even then distance functions need to be numba JIT compilable, and loading files is likely not going to meet that requirement. Sorry :-(

Are the vectors used apart from distance calculator because if not I can use dictionary keys as vectors. I would not be loading files in python but calling a c++ script which would return distance. Can this work? Thanks anyway!

It is slimly possible that you could manage to do this -- the catch being that the distance computation must be numba compilable. In theory you could write a distance function that uses ffi to call C++ functions directly and have that work. I have little experience with integrating ffi and numba so I don't know how easy that would be. Regardless I worry that the distance computation is going to be reading from disk for every single call, which is going to be terrifyingly slow, and make this approach unlikely to be worthwhile in the long run. To be honest you are likely to be better off writing C++ to do the brute force computation (if you write it intelligently, blockwise, you can save a vast amount of disk-reads).