Lots of errors when following Tooling Setup for BS5

I downloaded Bootstrap 5 alpha 2 directly from the Bootstrap website. Then followed the directions for Tooling Setup in the docs (macOS version 10.15.7).
When I ran npm start, I got a pile of errors. Not really sure what most of it means, but, here it is:
Montys-MacBook:bootstrap monty$ sudo npm start

><EMAIL_ADDRESS>start /Users/monty/Library/Mobile Documents/com~apple~CloudDocs/Projects/AdminTest/bootstrap
> npm-run-all --parallel watch docs-serve

><EMAIL_ADDRESS>watch /Users/monty/Library/Mobile Documents/com~apple~CloudDocs/Projects/AdminTest/bootstrap
> npm-run-all --parallel watch-*

><EMAIL_ADDRESS>docs-serve /Users/monty/Library/Mobile Documents/com~apple~CloudDocs/Projects/AdminTest/bootstrap
> hugo server --port 9001 --disableFastRender

Start building sites …

><EMAIL_ADDRESS>watch-css-main /Users/monty/Library/Mobile Documents/com~apple~CloudDocs/Projects/AdminTest/bootstrap
> nodemon --watch scss/ --ext scss --exec "npm-run-all css-lint css-compile css-prefix"

><EMAIL_ADDRESS>watch-css-docs /Users/monty/Library/Mobile Documents/com~apple~CloudDocs/Projects/AdminTest/bootstrap
> nodemon --watch site/assets/scss/ --ext scss --exec "npm run css-lint"

><EMAIL_ADDRESS>watch-js-main /Users/monty/Library/Mobile Documents/com~apple~CloudDocs/Projects/AdminTest/bootstrap
> nodemon --watch js/src/ --ext js --exec "npm-run-all js-lint js-compile"

><EMAIL_ADDRESS>watch-js-docs /Users/monty/Library/Mobile Documents/com~apple~CloudDocs/Projects/AdminTest/bootstrap
> nodemon --watch site/assets/js/ --ext js --exec "npm run js-lint"

[nodemon] 2.0.4
[nodemon] to restart at any time, enter `rs`
[nodemon] watching path(s): js/src/**/*
[nodemon] watching extensions: js
[nodemon] starting `npm-run-all js-lint js-compile`
[nodemon] 2.0.4
[nodemon] to restart at any time, enter `rs`
[nodemon] 2.0.4
[nodemon] watching path(s): scss/**/*
[nodemon] watching extensions: scss
[nodemon] starting `npm-run-all css-lint css-compile css-prefix`
[nodemon] to restart at any time, enter `rs`
[nodemon] watching path(s): site/assets/scss/**/*
[nodemon] watching extensions: scss
[nodemon] starting `npm run css-lint`
[nodemon] 2.0.4
[nodemon] to restart at any time, enter `rs`
[nodemon] watching path(s): site/assets/js/**/*
[nodemon] watching extensions: js
[nodemon] starting `npm run js-lint`

><EMAIL_ADDRESS>css-lint /Users/monty/Library/Mobile Documents/com~apple~CloudDocs/Projects/AdminTest/bootstrap
> npm-run-all --continue-on-error --parallel css-lint-*

><EMAIL_ADDRESS>js-lint /Users/monty/Library/Mobile Documents/com~apple~CloudDocs/Projects/AdminTest/bootstrap
> eslint --cache --cache-location .cache/.eslintcache --report-unused-disable-directives .

><EMAIL_ADDRESS>js-lint /Users/monty/Library/Mobile Documents/com~apple~CloudDocs/Projects/AdminTest/bootstrap
> eslint --cache --cache-location .cache/.eslintcache --report-unused-disable-directives .

><EMAIL_ADDRESS>css-lint /Users/monty/Library/Mobile Documents/com~apple~CloudDocs/Projects/AdminTest/bootstrap
> npm-run-all --continue-on-error --parallel css-lint-*

><EMAIL_ADDRESS>css-lint-stylelint /Users/monty/Library/Mobile Documents/com~apple~CloudDocs/Projects/AdminTest/bootstrap
> stylelint "**/*.{css,scss}" --cache --cache-location .cache/.stylelintcache

Oops! Something went wrong! :(

ESLint: 7.10.0

ESLint couldn't find the config "../.eslintrc.json" to extend from. Please check that the name of the config is correct.

The config "../.eslintrc.json" was referenced from the config file in "/Users/monty/Library/Mobile Documents/com~apple~CloudDocs/Projects/AdminTest/bootstrap/build/.eslintrc.json".

If you still have problems, please stop by https://eslint.org/chat/help to chat with the team.

npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR<EMAIL_ADDRESS>js-lint: `eslint --cache --cache-location .cache/.eslintcache --report-unused-disable-directives .`
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>js-lint script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR!      /Users/monty/.npm/_logs/2020-10-10T05_54_52_012Z-debug.log
[nodemon] app crashed - waiting for file changes before starting...

><EMAIL_ADDRESS>css-lint-vars /Users/monty/Library/Mobile Documents/com~apple~CloudDocs/Projects/AdminTest/bootstrap
> fusv scss/ site/assets/scss/

Oops! Something went wrong! :(

ESLint: 7.10.0

ESLint couldn't find the config "../.eslintrc.json" to extend from. Please check that the name of the config is correct.

The config "../.eslintrc.json" was referenced from the config file in "/Users/monty/Library/Mobile Documents/com~apple~CloudDocs/Projects/AdminTest/bootstrap/build/.eslintrc.json".

If you still have problems, please stop by https://eslint.org/chat/help to chat with the team.

npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR<EMAIL_ADDRESS>js-lint: `eslint --cache --cache-location .cache/.eslintcache --report-unused-disable-directives .`
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>js-lint script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR!      /Users/monty/.npm/_logs/2020-10-10T05_54_52_358Z-debug.log
ERROR: "js-lint" exited with 2.
[nodemon] app crashed - waiting for file changes before starting...
Built in 8281 ms
Error: Error building site: "/Users/monty/Library/Mobile Documents/com~apple~CloudDocs/Projects/AdminTest/bootstrap/site/content/docs/5.0/getting-started/browsers-devices.md:19:4": failed to render shortcode "rf.inline": failed to process shortcode: template: _inline_shortcode/docs/5.0/getting-started/browsers-devices.md/rf.inline:2:4: executing "_inline_shortcode/docs/5.0/getting-started/browsers-devices.md/rf.inline" at <readFile ".browserslistrc">: error calling readFile: file ".browserslistrc" does not exist
npm ERR! code ELIFECYCLE
npm ERR! errno 255
npm ERR<EMAIL_ADDRESS>docs-serve: `hugo server --port 9001 --disableFastRender`
npm ERR! Exit status 255
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>docs-serve script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR!      /Users/monty/.npm/_logs/2020-10-10T05_54_52_639Z-debug.log
ERROR: "docs-serve" exited with 255.
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>start: `npm-run-all --parallel watch docs-serve`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! code ELIFECYCLE
npm ERR! errno 143
npm ERR<EMAIL_ADDRESS>watch-css-main: `nodemon --watch scss/ --ext scss --exec "npm-run-all css-lint css-compile css-prefix"`
npm ERR! Exit status 143
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>watch-css-main script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! code ELIFECYCLE
npm ERR! errno 143

npm ERR!      /Users/monty/.npm/_logs/2020-10-10T05_54_52_818Z-debug.log
npm ERR<EMAIL_ADDRESS>watch-css-docs: `nodemon --watch site/assets/scss/ --ext scss --exec "npm run css-lint"`
npm ERR! Exit status 143
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>watch-css-docs script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
Montys-MacBook:bootstrap monty$
npm ERR!      /Users/monty/.npm/_logs/2020-10-10T05_54_52_839Z-debug.log

npm ERR!      /Users/monty/.npm/_logs/2020-10-10T05_54_52_848Z-debug.log

This is the contents of the debug.log mentioned above:
0 info it worked if it ends with ok
1 verbose cli [ '/usr/local/bin/node', '/usr/local/bin/npm', 'start' ]
2 info using<EMAIL_ADDRESS>3 info using<EMAIL_ADDRESS>4 verbose run-script [ 'prestart', 'start', 'poststart' ]
5 info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>6 info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>7 verbose lifecycle<EMAIL_ADDRESS>unsafe-perm in lifecycle true
8 verbose lifecycle<EMAIL_ADDRESS>PATH: /usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/node$
9 verbose lifecycle<EMAIL_ADDRESS>CWD: /Users/monty/Library/Mobile Documents/com~apple~CloudDocs/Projects$
10 silly lifecycle<EMAIL_ADDRESS>Args: [ '-c', 'npm-run-all --parallel watch docs-serve' ]
11 silly lifecycle<EMAIL_ADDRESS>Returned: code: 1  signal: null
12 info lifecycle<EMAIL_ADDRESS>Failed to exec start script
13 verbose stack Error<EMAIL_ADDRESS>start: `npm-run-all --parallel watch docs-serve`
13 verbose stack Exit status 1
13 verbose stack     at EventEmitter.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:3$
13 verbose stack     at EventEmitter.emit (events.js:198:13)
13 verbose stack     at ChildProcess.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.$
13 verbose stack     at ChildProcess.emit (events.js:198:13)
13 verbose stack     at maybeClose (internal/child_process.js:982:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:259:5)
14 verbose pkgid<EMAIL_ADDRESS>15 verbose cwd /Users/monty/Library/Mobile Documents/com~apple~CloudDocs/Projects/AdminTest/bootstrap
16 verbose Darwin 19.6.0
17 verbose argv "/usr/local/bin/node" "/usr/local/bin/npm" "start"
18 verbose node v10.16.3
19 verbose npm  v6.14.8
20 error code ELIFECYCLE
21 error errno 1
22 error<EMAIL_ADDRESS>start: `npm-run-all --parallel watch docs-serve`
22 error Exit status 1
23 error Failed at the<EMAIL_ADDRESS>start script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]

Why would you use sudo?
Either way this is something specific to your setup, you are better off asking on SO.


call home

Is call home supported - if not is there an expected time frame when it will be available?

Hi,
no, Call Home is not supported yet, but it should be implemented within 2, at most 3 months.
Regards,
Michal

any update on call home support ?
do we have this functionality getting merge with master branch
if not when is this planned and can be expected .


Update the macOS installation instructions

Based on #87 and others. (Issue #87 could then be closed)
brew links update is not supported anymore.
qt5 is now named simply qt and stored in directories with the same name.
It worked fine under both my Catalina Mac with latest brew 2.2.6.

@tpisto Hello, can you have a look at this PR ?

@tpisto The changes look good. Works well for me on Catalina 10.15.4

I don't know if this is specific to my machine but I also had to run brew install pkg-config. I didn't have the path mentioned in the readme (/opt/X11/lib/pkgconfig). This is on Catalina 10.15.5.

Thank you @frxnz.  brew install pkg-config also fixed my installation issue that was erroring in gyp.  I suggest this PR be updated with that.

I've updated the PR.
@tiholic can you review the new commit?
Thanks

@jybleau verified, and working good on my machine.


Added an extension point for custom function providers

As part of this, embarked on a major refactor:

Extracted interfaces for sql.Catalog and sql.ProcessList
Moved existing sql.Catalog to analyzer package
Moved ProcessList and MemoryManager out of Catalog
Changed Analyzer and Engine to take a DatabaseProvider instead of a Catalog

LGTM
Now that we've extracted an interface for Catalog I wonder about having DatabaseProvider as a separate concept. Feels like we could combine these

Yeah, I think we're moving in that direction.
If anything, the Catalog concept is a caching layer for the analyzer, not a public interface. Just didn't want to go quite that far in one push.


Consumer group rebalancing bug when switching from eager to cooperative consumers

Hello 👋!
We've been using franz-go for a while and have our consumers currently configured with the RangeBalancer. We want to switch to the CooperativeStickyBalancer and were trying to follow the instructions listed in both KIP-429 and the franz-go docs for CooperativeStickyBalancer which state that we essentially need to perform a double bounce to upgrade. However we noticed that during the first bounce where we add cooperative-sticky to our set of balancers, when our old range consumers would leave the consumer group we kept getting consumption lag on some of the partitions.
There's a minimal reproduction in this repo here.
In the reproduction we:

Spin up kafka and a producer that publishes events
Spin up a consumer that uses the [RangeBalancer] balancer
Spin up a consumer that uses the [CooperativeStickyBalancer, RangeBalancer] balancers
Shutdown the [RangeBalancer] consumer
The remaining consumer seems to revoke half of its partitions but never re-assigns them to itself

We also see that the issue seems to persist if we then spin up a new consumer that uses the [CooperativeStickyBalancer, RangeBalancer] balancers, some partitions are seemingly never re-assigned and are stuck. We found that performing a full restart of all the consumers in the consumer group once we're in this state fixes the issue (i.e. unsticks the partitions).
Let me know if we're missing something here!

Got the same issue on 1.14.0, 1.15.0
Tested with franz coop consumers + sarama and franz coop consumers + franz-go consumers with RR/Range balancers. Same effect.
My steps was:

Create topic with 12 partitions
Start 12 eager consumers(sarama/franz-go). Wait a few seconds -> First rebalance
Start 12 cooperative consumers(franz-go) -> Second rebalance
Shutdown eager consumers - Third rebalance
Consumers of partitions that were assigned to a CoopSticky clients on step 2 (before shutdown of Eager consumers) stucks right after third rebalance.

It becomes clear when each group of consumers uses its own ClientID as all consumers in Range assignment are sorted by MemberID. So the problem is stable to be reproduced if cooperative consumers MemberID(that is ClientID+suffix) appears earlier than eager ones after sorting.
For example lets say coop-consumers has ClientID = "a-consumer" and eager-consumers has ClientID = "z-consumer". This configuration stucks all the partitions after last rebalance.
Using same ClientID for all consumers leads to randomness&
Also looks like kafka itself thinks that all partitions were assigned after the last rebalance.
As mentioned above, full restart helps. Rolling restart also helps (start new consumers and then shutdown old) - looks like its because of leader change.

I'll probably be able to look at this on Friday.

Was looking into this a bit and what I think is happening is:

Say we have a consumer c0 with [RangeBalancer] balancers in a consumer group consuming from a topic t0 with partitions [t0p0, t0p1]
A new consumer c1 joins the consumer group with the [CooperativeStickyBalancer, RangeBalancer] balancers, say the assignment is now c0: [t0p0], c1: [t0p1]
Consumer c0 leaves the consumer group
This causes consumer c1 to eagerly revoke its prior assigned partitions (which would be t0p1) by nil-ing out nowAssigned
However lastAssigned remains populated with the old assignment (t0p1)
When that cooperative consumer now continues its consumer group rebalance it uses its lastAssigned as its current assignment
This gets sent as part of the JoinGroupMetadata as the currentAssignments which gets set as the OwnedPartitions for consumer c1

And I think that leaves us in a situation where c1 has revoked its previously owned partitions but performs the next rebalance thinking it still owns them.
I tried nil-ing out lastAssigned in groupConsumer::revoke which seems to fix the locally reproducible issue from my repo but I have no confidence that that's correct.

The fix is accurate, and the diagnosis is almost correct. The final step -- set as OwnedPartitions -- is a red herring. OwnedPartitions is used by the sticky balancer to guard against zombies (I'd have to read the code more to refresh truly what this guards).
The bug is right here: https://github.com/twmb/franz-go/blob/351e7fae879ce6bf712722f227893f41b66738bc/pkg/kgo/consumer_group.go#L588-L590
It's ok to nil out lastAssigned, because it's truly meant for tracking state between rebalances for cooperative group balancers specifically. It's not important to keep around the prior state for an eager balancer because well, for an eager balancer, there isn't meant to be any prior state at the start of every group session.
(also sorry for the delay in looking into this)

It's helpful. I don't think I fixed this in a branch locally. My own holdup on fixing this myself is that one of the KIPs is harder to implement than I thought. I spent some time on a plane implementing the fix and the more I worked on it, the bigger the scope turned out to be. I've set it aside and have been prioritizing some of my own stuff for a bit lately, so work has been essentially frozen. I aim to get back to this stuff sooner than later; if you go ahead and implement the fix and test before I get to it, I'll appreciate it -- no timeline on merging and releasing yet (though if I take too too long, I'll just go ahead and do a bugfix release).

Awesome, will give it a go 👍

I spent some time on a plane implementing the fix and the more I worked on it, the bigger the scope turned out to be

Are you referring to the fix for this issue or the KIP you were working on?

I'm referring to "KIP-951 - Leader discovery optimisations for the client". The client isn't implemented in a way to "move" partitions internally outside of the metadata loop, so hooking into this properly has been a PITA.


Docker App is complaining about a LicenseException

I followed the set up instructions and the proxy app builds ok. But once the docker-compose up is ran, the app complains about not being able to connect to New Relic
tls-proxy-app-1    | 2023-05-23T16:54:28,430+0000 [1 37] com.newrelic ERROR: Invalid license key, the agent is no longer reporting information. If this is not a misconfiguration, please contact support via https://support.newrelic.com/.
tls-proxy-app-1    | 2023-05-23T16:54:28,430+0000 [1 37] com.newrelic INFO: SQUID-TLS1.0-BUMP-UPGRADED is reconnecting
tls-proxy-app-1    | 2023-05-23T16:54:28,430+0000 [1 37] com.newrelic.agent.rpm.RPMConnectionServiceImpl INFO: Failed to connect to collector.newrelic.com:443 for SQUID-TLS1.0-BUMP-UPGRADED: com.newrelic.agent.LicenseException: {}
tls-proxy-app-1    | 2023-05-23T16:54:28,430+0000 [1 37] com.newrelic INFO: Host name is 672107a5b478, display host 672107a5b478 for application SQUID-TLS1.0-BUMP-UPGRADED
tls-proxy-app-1    | 2023-05-23T16:54:28,431+0000 [1 37] com.newrelic INFO: New Relic JFR Monitor is disabled: JFR config has not been enabled in the Java agent.

However, I have pulled the License Key directly from our New Relic account. I also stuck it in the app newrelic.yml location as well just in case that was the issue.
This is running on a vm in azure, ubuntu 22

readme updated


assets: use SipHasher instead of md5

Objective

Replace md5 by SipHasher as suggested in https://github.com/bevyengine/bevy/pull/8624#discussion_r1359291028
md5 is not secure, and is slow. use something more secure and faster

Solution

Replace md5 by SipHasher

Putting this PR in the 0.12 as once it's released, changing the hash algorithm will be a painful breaking change

Wouldn't it make more sense to use a faster hash like xxhash or wyhash? (ahash specifically tells you not to use it for hashing files as it doesn't have a fixed standard) Siphash is quite slow and afaik provides questionable value re: security (and if we want something actually secure blake3 seems to be faster, but using a cryptographic hash for assets seems questionable).
I'm not sure how hot asset hashes might be with eg. an asset streaming system, but imo for a game engine it's probably better to err on the side of more performance (especially since siphash only seems to manage ~15% of the throughput of a midrange nvme SSD these days).

I don't really have opinions on hashes, except avoiding md5. Which would you recommend?

If the intent is to be used for asset deduplication, I'd agree with @Elabajaba here. xxHash64 and wyhash are about the same speed and quality in terms of output. I personally would veer towards xxHash given its use of platform specific acceleration.
There's also meow_hash, which was explicitly made for the use case of large asset deduplication in game engines and heavily leverages platform specific instructions for acceleration. I'm no cryptoanalyst, so the exact security properties of the hash are alien to me. On a more practical side, there is a Rust implementation, but it seems to be under MPL and require C/C++ compiler toolchains to be available to build, so an alternative will probably be required.

For xxhash (specifically xxh3) it looks like there's 3 main choices in rust?
twox-hash doesn't seem to have SIMD implementations making their xxh3 implementation significantly slower.
xxhash-rust has compile time SIMD for sse and avx2 (but nothing for ARM), and seems to be fine but doesn't mark some unsafe functions as unsafe (the Boost Software License seems to basically be MIT, and has nothing to do with the Business Source License)
xxh3 has significantly fewer downloads, but has runtime SIMD detection for AVX2 and NEON (arm).

Agreed that this should be in 0.12, but no strong feelings on what hash algorithm to use.

switched to https://crates.io/crates/blake3


Figure out where to put Tools & Profiles pages

Currently they're under Community (Profiles not yet added) but this isn't intuitive.
See prior conversation in #16

I was trying to think of a word like integrations, plug-ins, extensions or similar that we could put both Tools and Profiles under in the top nav, but haven't come up with anything satisfactory yet.

Resources?

Agreed that Resources is a good name for the top nav item, with corresponding sidebar containing Tools, Profiles, and Tutorials. @a-mile will set this up.


Check plugin's engines.node version and warn if not met

Same as last time, but only warn so won't cause issues with plugins

Thanks :)


If forwarded port is not known, try to find it with x-forwarded-proto

The issue
My front load balancer (Google LB) doesn't set the X-Forwarded-Port header and my reverse proxy is not using TLS, that result with a X-Forwarded-Port set to 80 in my backend application.
The solution (@mouminoux)
I think that if X-Forwarded-Proto is set and the X-Forwarded-Port isn't, we should try to guess the port with X-Forwarded-Proto header before reverse proxy connection type (TLS).

Hi, it's a duplicate of #131, could you explain why?

Yes, but when my colleague push the PR, tests were KO !
Besides I find it strange that the tests are KO on master ...


Function not triggered by blob

I have an Azure function with a single trigger of the type 'Azure Storage Blob'. While actively working on (developing/testing) the function it responds almost directly to blob activity. A few days later the function is not started on the trigger of a new blob. If this was a webjob if would judge, based on the symptoms, that it was not in 'always on' mode. The Azure Function however uses the dynamic service plan and should always run & react to triggers, right?
Once I go to the Azure portal and open the Azure Function, it immediately runs.
Function Name: vatreturnprep
The timeline:

Last function test (succes): 2016-09-11T21:45:38
New blob uploaded in the Azure blob container: 2016-09-14T14:48
Azure function opened & Azure Function triggered: 2016-09-15T20:11

Azure Function activity:
2016-09-11T21:45:38.591 Function started (Id=537bf088-0d23-4ea6-bc81-6a575e8c4096)
2016-09-11T21:45:51.595 Function completed (Success, Id=537bf088-0d23-4ea6-bc81-6a575e8c4096)
2016-09-15T20:11:06.456 Function started (Id=7b87f523-40a4-415f-80d5-5a46133d9591)
2016-09-15T20:11:20.285 Function completed (Success, Id=7b87f523-40a4-415f-80d5-5a46133d9591)
Azure Blob Container:
Name    Modified                             Blob type  Size
file1.csv   11/09/2016 11:45:36 PM   Block blob  27.42 MB
file2.csv   14/09/2016 02:48:16 PM   Block blob  27.42 MB
I fail to find a reason that the function is not triggered until the exact moment I monitor the function in the Azure Portal, any chance this is a bug?

Can you confirm that you're on a Dynamic App Service Plan?  Azure Functions can be used on both a classic app service plan (where you do need to manually turn on Always On, see https://github.com/projectkudu/AzureFunctionsPortal/issues/557), or a dynamic plan.

Yes, it is using a Dynamic App Service Plan. I created the function from the 'Azure Functions page https://functions.azure.com, so the service plan was auto-created. Here's the service plan:

And the Azure Function:

@tohling will investigate, it definitely sounds like a bug.

I am also experiencing the same behavior for my function app with blob triggers.

@JohanKroese & @bullsfan127 can you check whether your storage account has diagnostic logs enabled for blob? The notification system relies on this.
To check:

in Portal, find your storage account
go to Diagnostics
Check that Status is On and 'Blob logs' is checked.

One more thing: if blog logging is enabled, you look see a Blob container named $logs in the storage account, and it should contain entries that match the time where you updated blobs.

I have 'Blob logs' checked and i had entries in $logs that matched the files that were placed

@bullsfan127 Can you share your function app name (that's the app name, not function name!), either directly or indirectly? This will help us investigate. Thanks!

Blob logging is enabled. The entry in $logs matches the time when the blob was inserted:
container: $logs\blob\2016\09\14\1200\000000.log  - 14 sept - 12:56:33 GMT
In the storage account tied to the Azure Function I find the matching blob receipt:
container: azure-webjobs-hosts\blobreceipts...\myblobfile. Datetime: 15 sept - 20:11:05 GMT
Note that the storage account that is the trigger-source for the Azure Function is a different storage account than the one that the Azure Function uses internally (named azurefunctions6fde45d2).

CC @mathewc Who was looking into it

Update on this: @jocawtho has identified the bug causing this. We have a fix, but it will take us a while to roll it out, since it is in core WebApps infrastructure, not the Functions runtime (i.e. not in this repo).

Any update on this, getting this in a customer deployment right now, although seems a bit schizophrenic as sometimes it is okay and other times I have to go in to kick it off?

The fix is currently being rolled out into production. The upgrade should be completely finished by the end of next week.

@jocawtho Can you update this issue when the fix has been deployed?

The fix to this issue has now been deployed fully to production.

Sorry to bump this, but I am still experiencing this issue. Is the fix rolled out globally? My function is deployed in the west Europe region.

Reactivating. @jocawtho can you investigate?
@ThorvaldBoe can you share your function app name (that's the app name, not function name!), either directly or indirectly?

Hi All,
I remember this problem 6 weeks ago and was told it was being rolled out within the next week. Believe that is the comment on the issue...
So yeah, be good to know a timeline.
Did speak to Chris at the Summit and he did mention a workaround of using a timer trigger in the same Function App that fired every 3 minutes or so (from memory) but not tried it as we went a different way.
M

On 2 Dec. 2016, at 00:53, David Ebbo<EMAIL_ADDRESS>wrote:
Reactivating. @jocawtho can you investigate?
@ThorvaldBoe can you share your function app name (that's the app name, not function name!), either directly or indirectly?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

The function app name is 'autobudget'
thanks!

@ThorvaldBoe can you also specify how you deployed your Functions into the app? e.g. was it using the Portal UI, git, WebDeploy, ...?

I used the portal and typed the code directly.
On 1 Dec 2016, at 19:18, David Ebbo <notifications<EMAIL_ADDRESS>wrote:
@ThorvaldBoehttps://github.com/ThorvaldBoe can you also specify how you deployed your Functions into the app? e.g. was it using the Portal UI, git, WebDeploy, ...?

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Azure/azure-webjobs-sdk-script/issues/691#issuecomment-264250360, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AXKvOQ6Pl7mEssODjbuH3dFA7Uu1Xhxlks5rDw9agaJpZM4J-V53.

Can you try one thing: go to the Portal Function UI and click the 'refresh' button in the lower left corner. Let's see if that helps.
Please let us know once you have done that so we can check our logs. Thanks!

Done.

I do see a record of the update at 2016-12-01 19:03:27Z. My suspicion is that it will start working now. But what's not clear is why it was not already updated when you created your functions in the portal.
Anyway, please check whether things in fact work now, and we'll go from there.

Hi,
thanks for your effort.
Unfortunately, this is still not working.
I wanted to test a bit to be sure before I came to a conclusion. There were uncertainty related to a few aspects of my function, for example related to an async method I used to send email. I thought I might potentially have overlooked something related to how async behaves in azure functions, and made a programming mistake. So in order to be completely sure, I decided to write a new function as simple as possible, with no async, just to see if I could reproduce the error.
The function (called "BlobTrigger") takes a blob as a trigger, and writes a new entry to an azure table containing the date/time of the operation. The source code is given below so that anyone can test it out.
When testing, I found that while having the function app blade open in the portal, everything behaves nice. When I close it, it works for a minute or two, then the function seems to fall asleep, until I open the function app blade in the portal again.
This should be quite straightforward to test. I am surprised nobody else have reported this. Am I the only one using Azure functions with blob trigger, or am I doing something wrong...?
#r "Microsoft.WindowsAzure.Storage"

using System;
using Microsoft.WindowsAzure.Storage.Table;

public static void Run(Stream myBlob, TraceWriter log, ICollector<BlobUpload> outputTable)
{
    log.Info($"C# blob trigger function processed: {myBlob}");
    BlobUpload bu = new BlobUpload();
    Guid id = Guid.NewGuid();
    bu.PartitionKey = id.ToString();
    bu.RowKey = id.ToString();
    bu.UploadDate = DateTime.Now;
    outputTable.Add(bu);
}

public class BlobUpload : TableEntity {
    public DateTime UploadDate { get; set; }
}

Hi,
I have a Event Hub Trigger function app with consumption plan. It has same problem. It only works when I open it in portal UI.

Yeah keeping the blade open is how I solved it. Still works using that when the steaming service goes to sleep.

On 3 Dec. 2016, at 05:57, ThorvaldBoe<EMAIL_ADDRESS>wrote:
Hi,
thanks for your effort.
Unfortunately, this is still not working.
I wanted to test a bit to be sure before I came to a conclusion. There were uncertainty related to a few aspects of my function, for example related to an async method I used to send email. I thought I might potentially have overlooked something related to how async behaves in azure functions, and made a programming mistake. So in order to be completely sure, I decided to write a new function as simple as possible, with no async, just to see if I could reproduce the error.
The function (called "BlobTrigger") takes a blob as a trigger, and writes a new entry to an azure table containing the date/time of the operation. The source code is given below so that anyone can test it out.
When testing, I found that while having the function app blade open in the portal, everything behaves nice. When I close it, it works for a minute or two, then the function seems to fall asleep, until I open the function app blade in the portal again.
This should be quite straightforward to test. I am surprised nobody else have reported this. Am I the only one using Azure functions with blob trigger, or am I doing something wrong...?
#r "Microsoft.WindowsAzure.Storage"
using System;
using Microsoft.WindowsAzure.Storage.Table;
public static void Run(Stream myBlob, TraceWriter log, ICollector outputTable)
{
log.Info($"C# blob trigger function processed: {myBlob}");
BlobUpload bu = new BlobUpload();
Guid id = Guid.NewGuid();
bu.PartitionKey = id.ToString();
bu.RowKey = id.ToString();
bu.UploadDate = DateTime.Now;
outputTable.Add(bu);
}
public class BlobUpload : TableEntity {
public DateTime UploadDate { get; set; }
}
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

@ThorvaldBoe Just want to report that I'm having the exact same behaviour as you. Blobtrigger only works when you've got the blade open.
I guess I'll work around it by inserting the object into a blob, and then adding the id to a regular storage queue.

Think it is safe to conclude that this is a bug. Hopefully MS will fix it soon. Your move, Microsoft! :)

@ThorvaldBoe I took a look at your app specifically and I can confirm that the issue is on our side and is not specific to your function code. Sorry about the issue - we'll keep investigating and try to figure out what's going on.
In the meantime, I'm attempting a mitigation by rebooting one of our infrastructure nodes to see if that gets your function to start triggering properly when the portal is not running. Let me know if you continue to see this behavior.

No worries, thanks for looking into it.
I guess a few glitches are unavoidable in the beginning, but as it matures, Azure functions are really going to rock! :)

For what it's worth, we actually experienced the same issue when triggering on a azure queue instead. Maybe this is an EU West issue or something? This effectively renders function triggers pretty useless.

@EmilBechMadsen can you share your function app name (that's the app name, not function name!), either directly or indirectly? I'd like to confirm whether it's the same issue and, if so, your additional data may help us narrow this down more quickly. Thanks!

@cgillum Hi Chris. Yep. It's "lasso-services". We've switched it to a queuetrigger, and then disabled it when it wasn't working in favour of a traditional webjob.

@EmilBechMadsen Thanks for the quick response. I see you have two queue-triggered functions. The first one is NewsReloaderFunction with a connection of lassofunctions_STORAGE, and our telemetry shows that this queue doesn't exist in your storage account.  Perhaps this function was misconfigured?  It's still enabled too.
The second function, TargetGroupExportFunction, has a similar problem though is a little more nuanced. In this case, our system is looking for a queue named exportsqueue in the default storage account (AzureWebJobsDashboard). However, I also noticed that your function.json actually points to a different storage account, LassoStorageNew, which does contain this queue. I'm guessing what happened is that you initially configured your queue trigger with the default storage account, but then switched to the new storage account. What can happen is if you make changes to function.json in a way that is not supported (e.g. editing the file directly in Kudu, etc) then our infrastructure won't notice the change.  The way to fix this is to either publish your function using Git or WebDeploy, or you can navigate to the portal and either click the Refresh button for your bindings or you can make a simple no-op change to update the trigger registration. I suspect this function will work correctly if you simply re-enable it using the portal (that should cause a trigger registration update).
So just to clarify for anyone else who is following this thread, I think these are two different issues. ThorvaldBoe's issue is not yet understood and we're still investigation.

@cgillum Aha. Well that would explain things. Thanks for the pointers. I changed the storage account this way because the interface does not allow you to configure it to use classic storage accounts.
Just in case you missed this point: It did actually work and triggered on the classic queue when I had the blade open, but I guess the automatic triggers outside the editor works differently.

@EmilBechMadsen Yeah, that's expected. Unfortunately there is a synchronization that needs to happen between parts of our system to ensure things continue working when the portal is closed. That synchronization is what doesn't happen when manual edits are made. Sorry about the confusion.

I believe I've identified the issue with blob triggers and am working on a fix. I'm going to try and squeeze this into the next production deployment, which is starting very soon but may take about a week to complete.  I'll circle back once the fix has made it into all of our production data centers. Thanks for your patience on this and for reporting the issue!

Hi, I am still experiencing the exact same issue, except with the 'ServiceBusTopicTrigger-CSharp'. Is there a fix for this yet?

No fix yet I don't think but I did find a workaround...
If you create a TimerTrigger in the same Function App, and set it to run every 9 minutes (which I chose because the Log Stream lasts for 10 so I guessed) then the app keeps running it seems.
Okay you get execution costs associated with it, but I literally just took the code as it is created in a TimerTrigger and it seems to work okay.

On 13 Dec. 2016, at 22:25, KeishaW<EMAIL_ADDRESS>wrote:
Hi, I am still experiencing the exact same issue, except with the 'ServiceBusTopicTrigger-CSharp'. Is there a fix for this yet?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

@KeishaW This issue is specifically tracking blob triggers. Service Bus triggers won't be affected. One thing that folks commonly run into with Service Bus triggers is that their connection strings do not contain the Manage permission, which is currently required. In any case, I suggest you open a new item for that.

@cgillum We've been discussing the ServiceBus AccessRights issue in an internal email thread, but I agree we should have a work item tracking this. I've opened https://github.com/Azure/azure-webjobs-sdk-script/issues/1048.

Hi Folks
I am also facing the same issue for last 2 weeks. I have a Event Hub Trigger function app with consumption plan. It was working, when I open the portal in UI & continue to run for 3-4 hours , after that it automatically sleeps, when no request coming to event hub.
Next day when request come again , it is not triggering, until I open portal.
I have to swap forcefully from Consumption Plan to App Service Plan to run this.
When we can expect fix for Consumption Plan????
Thanks.

@navilwayne This issue only tracks functions triggered by blobs (see @cgillum's previous comment). If you are seeing something with other triggers, it is likely unrelated, and should be tracked separately.

@davidebbo  - I have post the new request - Azure Function Not Triggering by Event Hub  #122 under Azure/Azure-Functions.
Thanks

@navilwayne Thanks. Not that https://github.com/Azure/azure-webjobs-sdk-script/ is actually the correct repo for it.

Any update on this, my customer is still having to keep a browser window open just to fire the function, or go in regularly to process files?

@martinabbott just to make sure there is no misunderstanding (since there has been some in this issue), can you confirm that you are referring to a blob trigger and not something else? My understanding is the @cgillum got the fix deployed, but I'll let him confirm.

Hi David,
Yes blob trigger is the only issue I have.
Some more on this, I hadn't trigger my Function for some time but had deployed a Timer Tigger Function which had solved the issue previously.
When checking again this week, even opening the blade didn't work and the blob trigger would not fire at all, even though the Timer Trigger was running.
I know this was a problem because adding a new Blob Trigger worked so it's like my original Blob Trigger had become unregistered.
Cheers,
Martin

On 8 Jan 2017, at 02:40, David Ebbo<EMAIL_ADDRESS>wrote:
@martinabbott just to make sure there is no misunderstanding (since there has been some in this issue), can you confirm that you are referring to a blob trigger and not something else? My understanding is the @cgillum got the fix deployed, but I'll let him confirm.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

If it doesn't run even going to portal, then it must be a different category of issues than the one Chris fixes (which was only about waking up the Function App). Does the blob function run correctly when you manually trigger it from the portal?
Can you share your function app name (that's the app name, not function name!), either directly or indirectly? As well as the blob function name within it.

As we found in the other issue, the problem for @martinabbott was that the function was disabled in the function.json.
Closing this issue now as things should be working for everyone.
If someone still sees the case of a blob triggered function that 'falls asleep' when portal is closed, please do let us know.

@davidebbo the issue raise in 1103 is different to this one, function becoming disabled after a long period of inactivity, I can confirm that I am still able to see this particular issue in my Function App.
My function writes data to a database. If I close the browser and wait a period of time, I just waited 90 minutes, then upload a file, my database is not updated.
As soon as I open a browser window to the Function App blade my database gets updated.
So I don't believe this problem has been resolved.
Same function and Function App details as discussed previously.

I've encountered the same issue.
I was about to deploy an azure blob-triggered function to a client, but can't deploy it as long as this bug is open.
I've also created a small test case to be sure it's happening as described here:

Create a 1minute time-trigger function which writes it's operation logs to a storage account.
Create a blob-trigger function which monitors this storage account.
As long as the Azure portal was open - I could see invocations of the blob-trigger function every minute in "Manage" tab in the function app.
I closed all azure portal browser tab, waited for 15 minutes.
When I reopened the "Manage" tab, there were no invocations of the blob-trigger function, although there were invocations of the time-trigger-

Is there a timeline for fixing this issue ?

@martinabbott your function app is definitely getting woken up, so the fix discussed above is working. The question is why it's not processing your blob function. Can you share the UTC time of one specific incident where you add a new blob and you don't see it getting processed?

@liricooli thanks for sharing your app names. Looking at blob-trigger-test, I do see many invocations of the BlobTriggerJS1 function, but I don't know whether it was when you had portal open or not. Can you also share the UTC time of an instance where you didn't have the portal open and the function failed to be called?

@davidebbo thanks for the quick reply.
I closed the portal yesterday, January 11th, at 12:15 PM and reopened it at about 12:40 PM.

@liricooli but at which point did you add a new blob that needed to get processed? Note that after the app gets deactivated, it can take a longer for it to get restarted, and it could be that it would have worked on its own with a little more time.
Looking through our logs. I see that the scale controller detected some blob updates at 12:41:55, and woke up the site at that point. But note that when it detects it may be several minutes after it happens.
So the sequence was:

12:17: scale controller detected blob changes
Function app runs and processes everything
12:23: Function app idles out due to lack of activity
Around 12:33, you added a new blob (not sure exact time)
You waited a couple minutes after not seeing it get processed, and want to portal, which woke it up
12:41: Scale controller finally detected the change and wakes up the app, which at that point has already done the work. But if you had not gone to portal, it would have done it on its own.

Bottom line:

I believe it would have worked even if you had not gone to portal. Please do verify :)
We're aware that the scale controller detection is too slow, and are looking at possible improvements going forward

Hi @davidebbo,
I'm quite sure that I can recreate this issue at-will and would be happy to do that while you're looking at the logs in real time, if needed.
The sequence of events you described is not quite what happened as far as I see it.
It's not that I added a new blob at ~12:23, but I was automatically and continuously adding new blobs every 1 minute, with a time-trigger function.
When the portal was open the blob trigger was triggered every minute, but once I closed the portal, the blob-trigger did not trigger even once.
The next time the blob-trigger triggered was only when I reopened the portal.
Here's the timeline as I see it:
~10:00 - 12:17:  portal open, the time-trigger was running every 1 minute, the blob-trigger was running as expected, triggering every minute as a new file hits the blob storage.
~12:18: I closed the portal.  the time trigger was still running every 1 minute from 12:18, and writing files that the blob-trigger is expected to monitor.
12:18 - 12:40:  I reopened the portal. I verified that the time-trigger was indeed running during the whole time, and that the blob trigger did not trigger even once during that period, although there were new files in the monitored container.
12:40-~130:00 I  left the portal open for some time and verified that the blob-trigger starts again.
This is why you see it started running in 12:41 - it was due to my manual opening of the portal.
as far as I grasp it without understanding anything about the system / architecture,  it does not seem like and issue with slowness of a component like you described in the bottom line, but rather something that should be running but isn't.

Yeah I'd echo that, I'm able to create at will if I don't have a Timer Trigger firing every 15 minutes that seems to keep it alive.
Currently at an event so I can't test but it's really easy to test anyway.

On 15 Jan 2017, at 18:52, liricooli<EMAIL_ADDRESS>wrote:
Hi @davidebbo,
I'm quite sure that I can recreate this issue at-will and would be happy to do that while you're looking at the logs in real time, if needed.
The sequence of events you described is not quite what happened as far as I see it.
It's not that I added a new blob at ~12:23, but I was automatically and continuously adding new blobs every 1 minute, with a time-trigger function.
When the portal was open the blob trigger was triggered every minute, but once I closed the portal, the blob-trigger did not trigger even once.
The next time the blob-trigger triggered was only when I reopened the portal.
Here's the timeline as I see it:
~10:00 - 12:17: portal open, the time-trigger was running every 1 minute, the blob-trigger was running as expected, triggering every minute as a new file hits the blob storage.
~12:18: I closed the portal. the time trigger was still running every 1 minute from 12:18, and writing files that the blob-trigger is expected to monitor.
12:18 - 12:40: I reopened the portal. I verified that the time-trigger was indeed running during the whole time, and that the blob trigger did not trigger even once during that period, although there were new files in the monitored container.
12:40-~130:00 I left the portal open for some time and verified that the blob-trigger starts again.
This is why you see it started running in 12:41 - it was due to my manual opening of the portal.
as far as I grasp it without understanding anything about the system / architecture, it does not seem like and issue with slowness of a component like you described in the bottom line, but rather something that should be running but isn't.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

I set up a similar repro with one function in one app adding blobs on a timer, and the other function (different app) consuming them. For me, it is working very consistently with the portal closed. At most, the processing happens a few minutes late, and it is well understood why.
@liricooli in your case, I can see from our logs that you went to the portal at 12:35, not 12:41. 12:41 is when the scale controller detected the change and ping the app (which by that point was already up).
If you want to test this, please just keep it running without going to the portal, and observed whether things really are stuck, or end up getting processed a little late. Please let me know when the app is setup (and the two app names, if different from above). @martinabbott, same thing if you get a repro going.

@davidebbo I closed the portal now and would not open it in ~24 hours.
Will report back with another comment when I open it again.

@davidebbo Re-opened the portal now. will edit this comment with results later

@liricooli so I'm looking at your app and trying to make sense of your functions.
In the blob-trigger-upload-test app, you have a TimerTriggerJS1 that is getting triggered every minute. But that function doesn't appear to do anything. i.e. it doesn't have any output bindings that would create a blob. Isn't that the Function that should be created a blob every minute? If not, who is doing that?

sorry for not replying earlier - I was busy getting married :)
You are correct that TimeTriggerJS1 function in blob-trigger-upload-test app is not doing anything.
However, this function is configured to write diagnostic logs to a container. This is the container our blob trigger function is monitoring.

@liricooli First congrats!! 🍾 🎉
So I looked into your scenario in more details, and I now understand exactly what's going on. The problem is that the diagnostic logs settings you're using don't really work with Function apps. I just opened https://github.com/projectkudu/AzureFunctionsPortal/issues/885 to track improving this.
So effectively, the issue in your case is not that the function listening to the blobs (in target app) is not waking up, but is that no blobs are getting produced at all unless you have the portal opened on the source app. You can see that by looking at the blob container in Storage Exporer, but with and without the portal opened.
Bottom line: to really test this, you need to have your source function produce some blobs by using a blob output binding. And in my own test, this works very well even after closing the portal.

The fix for the blob trigger issue has been fully deployed to production (it's been there for a while now) and I haven't seen any new reports of problems (other than slowness or user config issues, which we can track elsewhere) so I think we can close this issue.

So I’ve now tried this and it appears as though it is working.
I uploaded a file, the function simply writes out details including the current date and time to a storage Table.
The function did process the file around 6 minutes after I uploaded.
From: Chris Gillum<EMAIL_ADDRESS>Sent: Tuesday, 31 January 2017 1:54 AM
To: Azure/azure-webjobs-sdk-script<EMAIL_ADDRESS>Cc: Martin Abbott<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Azure/azure-webjobs-sdk-script] Function not triggered by blob (#691)
The fix for the blob trigger issue has been fully deployed to production (it's been there for a while now) and I haven't seen any new reports of problems (other than slowness or user config issues, which we can track elsewhere) so I think we can close this issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/Azure/azure-webjobs-sdk-script/issues/691#issuecomment-276136814 , or mute the thread https://github.com/notifications/unsubscribe-auth/AEVasYAVEipKzzpcB0BQ2zartBhWJUYyks5rXiPSgaJpZM4J-V53 .  https://github.com/notifications/beacon/AEVasXvWWHCswZdPOaNPngc6QCbLRAVUks5rXiPSgaJpZM4J-V53.gif

I think we're experiencing a similar issue in which files are not being picked up by a blob trigger function.
Today we added 5 files to a container which weren't processed for just over 30 mins. Someone then loaded the function blade and they were picked up.
Is there anything we can do to diagnose this? From following this thread - it looks as if logs were piped into the $logs container shortly after the files were added. But in the function storage account blob receipts and host logs were only added after someone loaded the function app up via the portal.

@Nosmadas Can you share your function app name (that's the app name, not function name!), either directly or indirectly, as well as the UTC time of the incident? As far as we know, all cases are fixed now, so there are no know pending issues.

I am experiencing something similar with my bandata-complaint-photos-resize app. Logs was created in the log folder after uploading photos to blob, but no function running was occured. But then, after opening portal, photos were resized.
I went through this thread, by I haven't found anything that could help me run my function automatically. I would be grateful if you could help me in this matter.
I have Dynamic App Service Plan and Check that Status is On and 'Blob logs' is checked.

@rmaziarka as per above, to investigate, we need the approximate UTC time where you uploaded a blob and didn't see the function run. Also, please include the name of the function. Thanks!

Taking a look, I can see that your app is getting woken up on Feb 3 at 21:14, 21:20, 22:35, 22:44, 23:43. So it is correctly detecting new blobs and doing the right thing from what I can see. Do keep in mind that when the app is cold, blob detection can be delayed for several minutes.

It was woken on Feb 3 because I opened portal. Photos were uploaded day before.
Today I uploaded 5 photos to my blob at 08:43 UTC (2017-02-04). Nothing happened. Then hour later I opened portal and automatically photos were resized (function has started), at 10:09 UTC (2017-02-04).
My app is bandata-complaint-photos-resize, function is complaint-photos-resize.

@davidebbo The function app name is wlImporterFunction. 5 files were added to the blob container used in the blob trigger at approx 10:10 UTC (2017-02-03), I loaded the function blade at around 10:43 and they were then picked up.

@rmaziarka so looking at your function, you are processing blobs in place, i.e. replacing the original image by the resized image.
Looking at our logs, it's a bit puzzling as I see the scale controller is detecting changes to the blob at 10:16, but not at 8:43. i.e. it appears to detect the change that is caused by the execution of your function, but not the change caused by you adding the new files in the first place.
Couple questions:

How exactly are you adding the new blobs? i.e. via code, some tool, ...?
I wonder if the fact that both your trigger and your output are the same blob is triggering some issue. If you don't mind, would you be able to try changing the output binding to go to a different container, to see if that makes a difference? Thanks!

@Nosmadas your case is different, as the scale controller does not have any information about your triggers. There was an issue that was fixed yesterday that could cause that to happen when deploying via VS (or msdeploy). Can you try clicking the 'Refresh' button in the Functions UI (in the lower left, below Quickstart). Thanks!

@davidebbo Done!

@Nosmadas yep, I see the registration for both functions. Normally, processing will now happen with having to go to portal.

@davidebbo
I created new function complaint-photos-resize-2 (app name bandata-complaint-photos-resize) which adds temp at the end of the filename. And now it's working. Both from code (ASP.NET app) and Storage Exporer. I would not think about it :)
Would you be able to fix it somehow or should i need to create 2 functions:

first to resize photo and save with temp name
second to rename output file to previous name
?

@rmaziarka I set up a similar scenario where the function updates the new blob inplace, and it's actually working fine for me.
My guess is that there is some alternate issue at play. Thinking about it, it's hard to see how the fact that you update inplace could break things, because the fact that you do an implace update doesn't come into play until your function gets called, and if it gets called, we don't have the issue in the first place. So the inplace part is very likely a red herring here.

Hi, Guys.
I am experiencing exactly the same issue but with function app triggered by the Queue. I am also on Consumption plan. App Name: cm-image-ops, Function Name: image-merge. Should I open a new issue or the same fix as for blob trigger can be applied in my case?
Thank you.

@edspivak Please do open a new issue, as this one is specific to blob triggers. Thanks!

@davidebbo
I'm seeing this issue.
At around 4:00pm UTC we uploaded a blob. It's now 4:19 UTC and it still hasn't processed. At 4:20 UTC I will open the app. The app name is cjep-Blob-Efiling-partners.
Opened the app and it immediately processed.

@ASeale it looks like there may be an issue with your connection string. I see an error on our backend: "The storage account connection string was null, empty, or not found." Can you check that the connection name is valid?
We're working on a way to better show these messages to the user, and this should be coming in the next month or two. /cc @tohling

@davidebbo ok so, the connection string names were accurate. As a test I moved them from the "Connection strings" section in the Application Settings to the "Application settings" section in the Application Settings. Everything seems to be working now. I will run some more delayed tests just to make sure.

@davidebbo verified working. I waited 30 minutes before trying another test. It took it 8 minutes to finally process it, but it did end up getting it. Not sure why moving the connection strings from the connection string section to the application setting section worked, but it did.

@ASeale I would say it's a bug that it didn't work with Connection Strings. But for now, yes, please do use App Settings (there is no drawback).

Facing the same issue now

@kkanna please share your function app name (that's the app name, not function name!), either directly or indirectly, as well as a sample UTC time where it didn't fire and you think it should have. Also, indicate how long you waited.

Hello, I'm facing the same issue too
The connection string is in the app settings
'Blob logs' is checked
There are entries in $logs that matched the files
I have two function listening on the same container, but none of the two is triggering anymore.
The functions are in the same service plan where dummy6428 is
I been waiting for an hour now but nothing happened
Can you @davidebbo help?
Thank you

Thank you @davidebbo for your help!
Most of the 34 sites are no longer or very rarely used, but we definitely need to organize them better :)
I will periodically check the log before moving the functions to production!
Thank you again

I'm encountering this same issue. If I load up the portal it seems to work, I can wait 2-3 mintues, upload again and it seems to work. If I wait around 10 minutes nothing triggers.
and I get the following :
2018-08-24T14:09:14  No new trace in the past 8 min(s).
2018-08-24T14:10:14  No new trace in the past 9 min(s).
2018-08-24T14:11:14  No new trace in the past 10 min(s).
2018-08-24T14:12:14  No new trace in the past 11 min(s).

Assume this is on a consumption plan?
Is it v1?
Just as a test, as this worked for me, try setting a timer trigger to fire every 5 minutes and see if that solves it.
More workaround than solution.

On 24 Aug 2018, at 22:30, mesani<EMAIL_ADDRESS>wrote:
I'm encountering this same issue. If I load up the portal it seems to work, I can wait 2-3 mintues, upload again and it seems to work. If I wait around 10 minutes nothing triggers.
and I get the following :
2018-08-24T14:09:14 No new trace in the past 8 min(s).
2018-08-24T14:10:14 No new trace in the past 9 min(s).
2018-08-24T14:11:14 No new trace in the past 10 min(s).
2018-08-24T14:12:14 No new trace in the past 11 min(s).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

I've changed it from a consumption plan and will test it in a few mins to see if it runs ok . So is it because I'm using a consumption plan?
I was using Runtime version
Runtime version: 1.0.11959.0 (~1)
THanks for your quick response.

This seems to have done the trick. I waited 8 minutes this time tried it
and it seemed to work OK. Thanks lots for your help.
OK now when I read the documentation I see the resolution:
The default timeout for functions on a Consumption plan is 5 minutes. The
value can be increased for the Function App up to a maximum of 10 minutes
by changing the property functionTimeout in the host.json
https://docs.microsoft.com/en-us/azure/azure-functions/functions-host-json#functiontimeout
project file.
Am I missing something but I thought that even in a consumption plan that
the blob trigger would invoke an event and cal the function?
On Fri, Aug 24, 2018 at 3:40 PM, Martin Abbott<EMAIL_ADDRESS>wrote:

Assume this is on a consumption plan?
Is it v1?
Just as a test, as this worked for me, try setting a timer trigger to fire
every 5 minutes and see if that solves it.
More workaround than solution.

On 24 Aug 2018, at 22:30, mesani<EMAIL_ADDRESS>wrote:
I'm encountering this same issue. If I load up the portal it seems to
work, I can wait 2-3 mintues, upload again and it seems to work. If I wait
around 10 minutes nothing triggers.
and I get the following :
2018-08-24T14:09:14 No new trace in the past 8 min(s).
2018-08-24T14:10:14 No new trace in the past 9 min(s).
2018-08-24T14:11:14 No new trace in the past 10 min(s).
2018-08-24T14:12:14 No new trace in the past 11 min(s).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Azure/azure-functions-host/issues/691#issuecomment-415779891,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AeXtn0obUV2epuE6zXEmNRT-AbvxgVT9ks5uUBB1gaJpZM4J-V53
.

ok scrap that last comment.
Note
When you're using a blob trigger on a Consumption plan, there can be up to
a 10-minute delay in processing new blobs. This delay occurs when a
function app has gone idle. After the function app is running, blobs are
processed immediately. To avoid this cold-start delay, use an App Service
plan with Always On enabled, or use the Event Grid trigger. For more
information, see the blob trigger binding reference article
https://docs.microsoft.com/en-us/azure/azure-functions/functions-bindings-storage-blob#trigger
.
On Fri, Aug 24, 2018 at 4:06 PM, Martin Esani<EMAIL_ADDRESS>wrote:

This seems to have done the trick. I waited 8 minutes this time tried it
and it seemed to work OK. Thanks lots for your help.
OK now when I read the documentation I see the resolution:
The default timeout for functions on a Consumption plan is 5 minutes. The
value can be increased for the Function App up to a maximum of 10 minutes
by changing the property functionTimeout in the host.json
https://docs.microsoft.com/en-us/azure/azure-functions/functions-host-json#functiontimeout
project file.
Am I missing something but I thought that even in a consumption plan that
the blob trigger would invoke an event and cal the function?
On Fri, Aug 24, 2018 at 3:40 PM, Martin Abbott<EMAIL_ADDRESS>wrote:

Assume this is on a consumption plan?
Is it v1?
Just as a test, as this worked for me, try setting a timer trigger to
fire every 5 minutes and see if that solves it.
More workaround than solution.

On 24 Aug 2018, at 22:30, mesani<EMAIL_ADDRESS>wrote:
I'm encountering this same issue. If I load up the portal it seems to
work, I can wait 2-3 mintues, upload again and it seems to work. If I wait
around 10 minutes nothing triggers.
and I get the following :
2018-08-24T14:09:14 No new trace in the past 8 min(s).
2018-08-24T14:10:14 No new trace in the past 9 min(s).
2018-08-24T14:11:14 No new trace in the past 10 min(s).
2018-08-24T14:12:14 No new trace in the past 11 min(s).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Azure/azure-functions-host/issues/691#issuecomment-415779891,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AeXtn0obUV2epuE6zXEmNRT-AbvxgVT9ks5uUBB1gaJpZM4J-V53
.

ok this doesn't seem to have resolved it. I recreated the function but using the PremiumV2: 1 Small) plan and set:
always on -> On
HTTP version 2.0
I see in the analytics pane of the memory usage went right down about 10 mins ago which is I assume the app going dead.
I thought it might have been due to it being hosted on a consumption but it appears like it's not.
Is there something obvious I'm not doing?

The one thing that worked for me, and this was two years ago so the runtime has changed, was having another function running every 5 minutes or less that used a Timer Trigger and just logged.
Increases cost a bit, but the unit of compute is a Function App rather than a function of course so that worked for me.
I called my function KeepAlive, because that’s what it seemed to do!!

On 24 Aug 2018, at 23:57, mesani<EMAIL_ADDRESS>wrote:
ok this doesn't seem to have resolved it. I recreated the function but using the PremiumV2: 1 Small) plan and set:
always on -> On
HTTP version 2.0
I see in the analytics pane of the memory usage went right down about 10 mins ago which is I assume the app going dead.
I thought it might have been due to it being hosted on a consumption but it appears like it's not.
Is there something obvious I'm not doing?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

After about 24 hours hosted on an always on plan it started to stay alive and has been working successfully for me. albeit, a little more costly but it does work which is my main objective.

For v2 Function Apps, please check if you have the queue MaxPollingInterval configure as an intenger in host.json - we had the following bug here: https://github.com/Azure/azure-webjobs-sdk/pull/1988. Behind the scenes for BlobTrigger functions we use an intermediate queue for processing, and for people with an incorrectly configured MaxPollingInterval value, this bug meant that the queue polling wasn't happening when it should be.
For those still affected, please check this and let me know.

Hi @davidebbo & @mathewc,
I am also running into this problem with blob triggers taking long to fire. Hopefully you can help me with the information I have put together of my situation.
Background
I have a blob trigger function watching a container named 'imageuploads-new'.
I upload images into 'virtual folders' inside the container from a web page and the upload from the webpage goes very fast.
Problem
The problem I have is that very often when I upload the images into the container, most of them gets picked up by the blob trigger almost immediately but some of the images takes very long to be detected by the blob trigger (ranging from a few minutes to 30-40 minutes delay at worst).
A while back I was experiencing delays like this, and then I added a 'keep instance warm' timer triggered function that is called every 4 minutes (as per the recommendation of some other users). At the time that seemed to have solved the problem with delays, but lately I have started to experience delays in blob triggers being fired again. This is causing big issues for me.
I have recreated examples of these delays and tried to give a trace of it so that someone at MS hopefully can figure out what is going wrong for me and help me to solve the issue.
Details about the function app

C# class library that runs in version ~1.
Runs under a consumption plan
I don't want to share the function name publicly, but to help you find it indirectly, here is a function start call: 15:57:55.489 Function started (Id=d66732f3-5e66-4926-97cd-6aeb4626db71)
The function that listens to blob triggers is named 'ImageUploads_BlobTriggerNewImage'
I use Application Insights tracing to be able to see when the blob trigger have been fired and to debug. I hope that you can access the application insights trace logs to extract more information?

Below are examples to illustrate where some of the uploaded images were processed after a delay. All times are as displayed as in the trace logs and are in my local time (UTC+1).
Example 1

I added 111 small images (between 115-770kb) at 12:52 to 'imageuploads-new/6078e80c-ab34-43d1-b078-47076c5f7621/[unique uuid for each image].jpg
110 of the 111 images had been detected by the blob trigger 12:52:35, so very fast
The last image was detected by the blob trigger 12:58:40, a 6:05 minute delay compared to the other images
All these entries can be found as trace logs in Application insights if you search for the string "ImageUploads_BlobTriggerNewImage fired for blob 'imageuploads-new/6078e80c-ab34-43d1-b078-47076c5f7621"

Example 2

I added 111 small images (between 115-770kb) at 12:57 to 'imageuploads-new/b6866bcf-995e-46da-a02a-2a80c0500c9c/[unique uuid for each image].jpg
102 of the 111 images had been detected by the blob trigger 12:58:09, so very fast
The last 9 images were detected by the blob trigger 13:04:54, a 6:43 minute delay compared to the other images
All these entries can be found as trace logs in Application insights if you search for the string "ImageUploads_BlobTriggerNewImage fired for blob 'imageuploads-new/b6866bcf-995e-46da-a02a-2a80c0500c9c"

Example 3

I added 240 large images (between 5-8.8 mb in size) at 15:22 to 'imageuploads-new/eb083d7b-7bb3-4243-8c8e-3245f6a49575/[unique uuid for each image].jpg
These images took longer to finish uploading because of their size (about 4 minutes until last one), but blob triggering started very fast after the first images arrived in the container
238 of the 240 images had been detected by the blob trigger 15:24:27
The last 2 images were detected by the blob trigger 15:26:31, a 2:04 minute delay compared to the other images
All these entries can be found as trace logs in Application insights if you search for the string "ImageUploads_BlobTriggerNewImage fired for blob 'imageuploads-new/eb083d7b-7bb3-4243-8c8e-3245f6a49575"

Example 4

I added 800 small images (between 44-98kb) at 15:51 to 'imageuploads-new/9150ddce-bfdd-479c-a5f1-680168b1e216/[unique uuid for each image].jpg
The upload went very fast, 56 seconds
786 of the 800 images had been detected by the blob trigger 15:53:27 (2:21 minutes in total from first to last)
The last 14 images were detected by the blob trigger 15:57:51, a 4:24 minute delay compared to the other images
All these entries can be found as trace logs in Application insights if you search for the string "ImageUploads_BlobTriggerNewImage fired for blob 'imageuploads-new/9150ddce-bfdd-479c-a5f1-680168b1e216"

@jaltin I recommend you create a new issue with your details, since this is a closed issue about functions not being triggered at all. I was able to use the details you gave above to see some of the delays you mentioned in our system logs - e.g. a series of 111 blobs being processed all on the same worker instance with 110 of them all being processed in the first minute, but the last blob being started 6 minutes later. That delay was at 2018-12-07 11:52:37.530.
However, I do notice that at that time there are a lot of other blobs from other containers being processed by the same function at that time. So perhaps your issue is that you're expecting all the blobs for a particular folder upload to all be processed around the same time, but in reality the function is processing other container blobs at that time, increasing latency.
One suggestion: I'm not sure how resource intensive your function is, but if it is low, you could increase per instance parallelism by upping your queues BatchSize/NewBatchThreshold knobs. That would allow each instance to process more blobs in parallel.

Thanks for looking into this @mathewc! I have created a new issue for it - #3869.


Tests: add tests to pkg/envoy/lds

a) Add test cases for pkg/envoy/lds NewResponse():

many error scenarios not covered
WASM Stats enabled case not covered.
ingress routes exists scenario not covered

b) Add test cases for pkg/envoy/lds listenerBuilder.getOutboundFilterChainPerUpstream().
Several scenarios not covered:

No upstream service exists
Retriving protocol to port map failed for a upstream
Some error returning cases.

Ref #1489

https://github.com/openservicemesh/osm/pull/3486 partially resolves this issue. It covers line 24-25 of NewResponse.
For other parts of lds/response.go, it's difficult to write tests, since there is no proper way to mock some internal methods. This requires a larger scale refactor on the implementation.


pubsub kafka can not be used

I'm trying to use kafka as pubsub backend according to the dmo:
https://github.com/azure-octo/dapr-kafka-csharp/blob/master/deploy/kafka-pubsub.yaml
I changed the brokers section and here is my yaml:
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: dapr-kafka-pubsub
  namespace: my-namespace
spec:
  type: pubsub.kafka
  metadata:
    - name: brokers
      value: "<IP_ADDRESS>:9092,<IP_ADDRESS>:9092"
    - name: authRequired
      value: "false"

I can ping and telnet the kafka broker successfully, and connect to it with kafka's official java SDK.
However, that yaml keeps my daprd from starting, and logs as follow:
error intializing pub sub pubsub.kafka/v1: kafka: client has run out of available brokers to talk to (Is your cluster reachable?)

and then daprd exits.
It's ok to use redis as pubsub backend, I can't even start the sidecar using kafka as pubsub backend.
Any idea how to solve this question？

Is tls enabled on your Kafka backend?

@darren-wang can you try pointing to a Kafka service and not direct pod IP? also, what Kafka installation are you using? I recommend you test with this one: https://bitnami.com/stack/kafka/helm. (assuming you're using Kubernetes)

@darren-wang can you try pointing to a Kafka service and not direct pod IP? also, what Kafka installation are you using? I recommend you test with this one: https://bitnami.com/stack/kafka/helm. (assuming you're using Kubernetes)

@yaron2 Yeah, thanks, I'm deploying my dapr services and dapr apps on k8s, but our kafka cluster are not since they are hosted by another team and they only provides server IPs. I have to adapt to them, sad.
Our kafkas are of version 0.10.x. I think it is pretty old and could this be the reason?
Also, do you know the supported version list of kafka backends so I can check if it is version reasons. And a clear version support list is really important for  corporate users to adopt dapr.

Same issue here.
Redis, rabbitmq is working fine, but Kafka keep getting error "Invalid receive (size = 369295616 larger than 104857600)".
Tried Bitnami kafka, wurstmeister/kafka, Offical APACHE KAFKA with no luck.
Error info
dapr:
08T04:49:36.899888548Z" level=warning msg="error initializing pub sub pubsub.kafka/v1: kafka: client has run out of available brokers to talk to (Is your cluster reachable?)" app_id=orderprocessing instance=086ac359ee2c scope=dapr.runtime type=log ver=1.6.0

Kafka:
[2022-03-08 05:15:49,375] WARN [SocketServer listenerType=ZK_BROKER, nodeId=1001] Unexpected error from /<IP_ADDRESS>; closing connection (org.apache.kafka.common.network.Selector)

org.apache.kafka.common.network.InvalidReceiveException: Invalid receive (size = 369295616 larger than 104857600)

at org.apache.kafka.common.network.NetworkReceive.readFrom(NetworkReceive.java:105)

at org.apache.kafka.common.network.KafkaChannel.receive(KafkaChannel.java:452)

at org.apache.kafka.common.network.KafkaChannel.read(KafkaChannel.java:402)

at org.apache.kafka.common.network.Selector.attemptRead(Selector.java:674)

at org.apache.kafka.common.network.Selector.pollSelectionKeys(Selector.java:576)

at org.apache.kafka.common.network.Selector.poll(Selector.java:481)

at kafka.network.Processor.poll(SocketServer.scala:989)

at kafka.network.Processor.run(SocketServer.scala:892)

at java.lang.Thread.run(Thread.java:748)

Code
repo johnseed/dapr-pubsub-demo
pubsub yaml
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: order_pub_sub
spec:
  type: pubsub.kafka
  version: v1
  metadata:
  - name: brokers # Required. Kafka broker connection setting
    value: "kafka:9092"
  - name: authType # Required.
    value: "none"
  - name: authRequired
    value: "false"
scopes:
  - orderprocessing
  - checkout

Pub
string PUBSUB_NAME = "order_pub_sub";
string TOPIC_NAME = "orders";
Random random = new Random();

while (true)
{
    try
    {
        System.Threading.Thread.Sleep(5000);
        int orderId = random.Next(1, 1000);
        CancellationTokenSource source = new CancellationTokenSource();
        CancellationToken cancellationToken = source.Token;
        using var client = new DaprClientBuilder().Build();
        //Using Dapr SDK to publish a topic
        await client.PublishEventAsync(PUBSUB_NAME, TOPIC_NAME, orderId, cancellationToken);
        Console.WriteLine("Published data: " + orderId);
    }
    catch (Exception ex)
    {
        Console.WriteLine(ex);
    }
}

Sub
    [ApiController]
    public class CheckoutServiceController : Controller
    {
        //Subscribe to a topic
        [Topic("order_pub_sub", "orders")]
        [HttpPost("/checkout")]
        public string GetCheckout([FromBody] int orderId)
        {
            Console.WriteLine("Subscriber received : " + orderId);
            return "Subscriber received : " + orderId;
        }
    }

Kafka
  kafka:
    image: wurstmeister/kafka
    container_name: kafka
    ports:
      - 9092:9092
    environment:
      KAFKA_ADVERTISED_HOST_NAME: kafka
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_CREATE_TOPICS: "orders:1:1"
    restart: unless-stopped

Will take a look

@johnseed can you help have a try with this pubsub yaml?
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: order_pub_sub
spec:
  type: pubsub.kafka
  version: v1
  metadata:
  - name: brokers # Required. Kafka broker connection setting
    value: "kafka:9092"
  - name: authType # Required.
    value: "none"
  - name: authRequired
    value: "false"
  - name: disableTls
    value: "true"
scopes:
  - orderprocessing
  - checkout

@johnseed can you help have a try with this pubsub yaml?
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: order_pub_sub
spec:
  type: pubsub.kafka
  version: v1
  metadata:
  - name: brokers # Required. Kafka broker connection setting
    value: "kafka:9092"
  - name: authType # Required.
    value: "none"
  - name: authRequired
    value: "false"
  - name: disableTls
    value: "true"
scopes:
  - orderprocessing
  - checkout

what is the minimum version of kafka cluster that this component support, I'm using kafka <IP_ADDRESS> and ip:port as brokers(e.g. <IP_ADDRESS>:9092) and  the sidecar failed with :
client has run out of available brokers to talk to (Is your cluster reachable?)

And I'm sure that the network is connected and the test cluster does not need authentication.
I think there should be a version list that our component supports.

@johnseed can you help have a try with this pubsub yaml?
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: order_pub_sub
spec:
  type: pubsub.kafka
  version: v1
  metadata:
  - name: brokers # Required. Kafka broker connection setting
    value: "kafka:9092"
  - name: authType # Required.
    value: "none"
  - name: authRequired
    value: "false"
  - name: disableTls
    value: "true"
scopes:
  - orderprocessing
  - checkout

what is the minimum version of kafka cluster that this component support, I'm using kafka <IP_ADDRESS> and ip:port as brokers(e.g. <IP_ADDRESS>:9092) and  the sidecar failed with :
client has run out of available brokers to talk to (Is your cluster reachable?)

And I'm sure that the network is connected and the test cluster does not need authentication.
I think there should be a version list that our component supports.

The default version is <IP_ADDRESS>, and you can define it with version. I am currently not sure the supported range but you can have a try by adding:
- name: version
    value: "<IP_ADDRESS>"

@johnseed can you help have a try with this pubsub yaml?
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: order_pub_sub
spec:
  type: pubsub.kafka
  version: v1
  metadata:
  - name: brokers # Required. Kafka broker connection setting
    value: "kafka:9092"
  - name: authType # Required.
    value: "none"
  - name: authRequired
    value: "false"
  - name: disableTls
    value: "true"
scopes:
  - orderprocessing
  - checkout

It worked! Thank you so much.

I'm using dapr-1.5.1, and,

I confirmed that brokers field supports IP1:PORT,IP2:PORT brokers string.
pubsub.kafka supports kafka <IP_ADDRESS>

here is my yaml:
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: pubsub_name
spec:
  type: pubsub.kafka
  version: v1
  metadata:
  - name: brokers
    value: "<IP_ADDRESS>:9092,<IP_ADDRESS>:9092,<IP_ADDRESS>:9092" # example
  - name: version
    value: "<IP_ADDRESS>"
  - name: authType
    value: "none"
  - name: authRequired
    value: "false"
  - name: disableTls
    value: "false"
  - name: skipVerify
    value: "false"

P.S.
dapr subscription needs kafka v<IP_ADDRESS> at least, so in our test with kafka <IP_ADDRESS>, only pulisher is available.


pino-loki global install

npm install -g pino-loki
This is not a programming question, but I was curious if I can get by with install pino-loki as a node app dependencies instead of globally on my server.

Yes of course you can
However, if you are using the CLI version you will need to run pino-loki using npx :
node myProgram.js | npx pino-loki ...


Normalize top-level declarations before encoding to SMT

Queries produced by the typechecker are normalized before being encoded to the SMT solver (see FStar.TypeChecker.Rel discharge_guard').
However, top-level declarations are also encoded to the SMT solver but these were not similarly normalized  before encoding.
This leads to weird discrepancies between query terms and top-level terms that cause proofs to fail. For example, consider this program:
module NormTypesForSMT

let ta = (bool * (i:int{0 <= i /\ i <= 8}))
let tb = (bool * (i:int{0 <= i /\ i <= 9}))
let tc = (bool * (i:int{0 <= i /\ i <9+1}))
let td = (bool * (i:int{0 <= i /\ i < 10}))

let a:ta = (true, 5)
let a':ta = (true, 5)

let b:tb = (true, 5)
let b':tb = (true, 5)

let c:tc = (true, 5)
let c':tc = (true, 5)

let d:td = (true, 5)
let d':td = (true, 5)

let test () =
  assert (a == a');
  assert (b == b');
  assert (c == c');
  assert (d == d');
  assert (c == d);
  assert (c' == d');
  assert (c == d')

The last three assertions here used to fail, since although tc and td are definitionally equal, the SMT encoding for them was producing different refinement types. This is no longer the case.
My patch is mainly confined to FStar.SMTEncoding.Encode where prior to encoding any term, I make sure to call norm_before_encoding.
I got an everest green with the patch. Had to fix up one proof in Vale.AsLowStar.Wrapper, but that failure seemed unrelated since there were no unfolds in sight. Didn't investigate further.

Thanks to Kevin Kane, @Chris-Hawblitzel, and @parno for reporting issues that led to this fix.

Cool, thanks for the quick fix!


Revive fpm based docker environemnt

In my opinion, the worst decision for https://github.com/sulu/sulu-docker/pull/51 is to replace nginx+fpm with apache.
I would suggest keeping the previous configuration ideally here and create apache-based environment as a separate project / separate docker-compose file here.
Is apache still a thing in php world in 2020?

Hey,
thanks for your feedback. What advantages do you see in using a two container solution?
Please keep in mind that this environment is not designed to use in production.
The goal is to provide an environment as simple as possible for quickly setting up a Sulu project.

Is apache still a thing in php world in 2020?
The advantage of apache is that there is an official PHP docker image that is well maintained.

Hey,
thanks for your feedback. What advantages do you see in using a two container solution?
Please keep in mind that this environment is not designed to be used in production.
The goal is to provide an environment as simple as possible for quickly setting up a Sulu project.

Is apache still a thing in php world in 2020?

The advantage of apache is that there a well maintained variant of the official PHP docker image.

Closing this because of inactivity.

Closing this because of inactivity.


What's my version?

I'm not sure if this is a feature request or a help request.
I've decided to use versionist for my api routing and active_model_serializers to manage my presentation of my objects in the json object. I'm using https://github.com/hookercookerman/active_model_version_serializers so that I can version my model serialization (no context with that gem needed to understand this issue).
I have a common base class for all my controllers of a given version, and right now it looks like this:
class Api::V20130701::BaseController < Api::ApiController
  def default_serializer_options
    {version: :V20130701}
  end
end

The version arg there tells active_model_version_serializers what version to use unless told otherwise. It matches my version from my routes file.
I would love to be able to get the current versionist module from the request somehow. I would like to get this from a standard place. That is agnostic to what options I've set up versionist with (header vs url param).
As an example, I'd be able to do something like:
class Api::V20130701::BaseController < Api::ApiController
  def default_serializer_options
    {version: api_version}
  end
end

Where api_version is a helper method added to ActionController::Base. I'm pretty indifferent to the mechanism used (params? env?), but I would like to get the version of the current request.
Thanks,
Adding routes.rb snippet just in case:
  namespace :api do
    api_version(:module => "V20130701",
                :header => {:name => "API-VERSION", :value => "20130701"},
                :defaults => {:format => "json"},
                :default => true) do

Was there any resolution on this issue?

@dan-corneanu Not really. I think it would be trivial to add something like this, but I'm still curious as to the use cases where you'd need this.

The goal was just not to have the String in the routes file, and also in the class. It's a minor point, but requires having the same string in a couple of places. Basically, I've routed the request via a version number to a given controller.
It's been a long time since I opened this. Since I never followed up answering Brian's very prompt response to my original question, it must not have been that important.


[GSSOC'23]  I want to improve the navbar

DESCRIPTION:-
I want to improve the typography, fonts hovering etc more appearing and attractive navbar with good colors and themes in general to improve UI|UX  and also good drop down animations .
PLEASE GIVE ME THE OPPORTUNITY TO FIX THIS
code of conduct
I follow Contribution Guidelines for this project

I want to work on this Project. Plzz assign it to me under GSSOC'23.

I noticed that the navbar is not responsive for small size screens.

The contact part deviates from its position.
SOLUTION -
We can make a hamburger icon for small screen sizes.
Kindly assign me this issue under GSSOC'23.
@Anupkjha2601
Thankyou.

I am a full-stack developer, so adding this feature is not a big task for me. so please assign me this and I am also a GSSOC 2023 contributor

Please contribute on big projects, leave it for beginners.
On Wed, May 24, 2023 at 5:40 PM shubham kumar @.***>
wrote:

I am a full-stack developer, so adding this feature is not a big task for
me. so please assign me this and I am also a GSSOC 2023 contributor
—
Reply to this email directly, view it on GitHub
https://github.com/Anupkjha2601/food-recipes-website/issues/99#issuecomment-1561004293,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A3JS7CPRB23BWN2UQL7PDELXHX3DNANCNFSM6AAAAAAYKD4AZI
.
You are receiving this because you commented.Message ID:
@.***>


Odd toolchain bug(?) (IDFGH-3298)

Environment

Development Kit:      [none]
Module or chip used:  [ESP32-WROVER-B]
IDF version: v4.2-dev-318-g605da33c3
Build System:         [CMake]
Compiler version: (crosstool-NG esp-2019r2) 8.2.0
Operating System:     Linux
Using an IDE?: VsCode
Power Supply: on-board 3v3 regulator

Problem Description
I have a "networkTask" class that manages ethernet, wifi, websockets etc. There is a member variable 'mNetworkSubscriber.' It's of type "subscriberHandle_t", which is a typedef'd QueueHandle_t. I was having some crashes when attempting to block on a queue using this QueueHandle, so I created a local queue in NetworkTask, and blocked on it. Oddly enough, that worked fine.
While trying to find out what was going on, I ended up writing the following lines of code:
(Note: mNetworkSubscriber is a queueHandle that is created by xQueueCreate in the NetworkTask constructor.
networkSubscriber is a queueHandle that is created by xQueueCreate in the context of the networkTask.)
    ESP_LOGE("", "member: %p, non-member %p", mNetworkSubscriber, networkSubscriber);
    mNetworkSubscriber = networkSubscriber;
    ESP_LOGE("", "member: %p, non-member %p", mNetworkSubscriber, networkSubscriber);

I got the following printout:
E (568) "" member: 0x20004136, non-member 0x3ffc28b0
E (568) "" member: 0x20004136, non-member 0x3ffc28b0

Expected Behavior
member equals non-member after assignment.
Actual Behavior
member variable retains its previous value after assignment
Quite strange behavior, which tells me that something is getting corrupted, or there is a bug in the toolchain preventing the value of mNetworkSubscriber from being modified. Let me know if you need anything else (project, elf files, etc). In order to provide that, we'll need to sign a mutual NDA, but I've used espressif's mutual NDA before at a different company, so that will not be an issue.

Hi @lucastcox, could you please try logging the address of mNetworkSubscriber and also the value of this pointer? I.e.
ESP_LOGE("", "member: %p, non-member %p &member %p this %p", mNetworkSubscriber, networkSubscriber, &mNetworkSubscriber, this);

and post the result? Thanks.

@igrr Sure. Here you go:
E (1439) : member: 0x16004136, non-member 0x3ffc7028
E (1449) : member: 0x16004136, non-member 0x3ffc7028
E (1449) : member: 0x16004136, non-member 0x3ffc7028 &member 0x400da600 this 0x400da600

And here is the backtrace when I attempt to block on the 'mNetworkSubscriber' queuehandle.
Guru Meditation Error: Core  0 panic'ed (StoreProhibited). Exception was unhandled.
Core 0 register dump:
PC      : 0x4008dc25  PS      : 0x00060933  A0      : 0x8008e977  A1      : 0x3ffc3830
0x4008dc25: compare_and_set_native at /home/lucas/Projects/RemoteIO/build/../esp-idf/components/soc/include/soc/compare_set.h:28
 (inlined by) spinlock_acquire at /home/lucas/Projects/RemoteIO/build/../esp-idf/components/soc/include/soc/spinlock.h:91
 (inlined by) vPortCPUAcquireMutex at /home/lucas/Projects/RemoteIO/build/../esp-idf/components/freertos/xtensa/include/freertos/portmacro.h:202
 (inlined by) vPortEnterCritical at /home/lucas/Projects/RemoteIO/build/../esp-idf/components/freertos/xtensa/port.c:394

A2      : 0x16004182  A3      : 0x0000cdcd  A4      : 0x00060923  A5      : 0x00060920
A6      : 0x0000abab  A7      : 0xb33fffff  A8      : 0x0000cdcd  A9      : 0x3ffc3830
A10     : 0x00000003  A11     : 0x00060923  A12     : 0x00060920  A13     : 0x00000001
A14     : 0x00000004  A15     : 0x3ffb48fc  SAR     : 0x00000005  EXCCAUSE: 0x0000001d
EXCVADDR: 0x16004182  LBEG    : 0x40087da4  LEND    : 0x40087dd2  LCOUNT  : 0x00000000
0x40087da4: memcpy at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/machine/xtensa/memcpy.S:168

0x40087dd2: memcpy at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/machine/xtensa/memcpy.S:201

ELF file SHA256: 6a2a6165d1553a0110ee19b5cb4788dbc2fb476bb8af075d70f266a044d2272d

Backtrace: 0x4008dc22:0x3ffc3830 0x4008e974:0x3ffc3860 0x400d9606:0x3ffc38a0 0x400da59d:0x3ffc38c0 0x400da609:0x3ffc3910 0x4008daad:0x3ffc3930
0x4008dc22: compare_and_set_native at /home/lucas/Projects/RemoteIO/build/../esp-idf/components/soc/include/soc/compare_set.h:28
 (inlined by) spinlock_acquire at /home/lucas/Projects/RemoteIO/build/../esp-idf/components/soc/include/soc/spinlock.h:91
 (inlined by) vPortCPUAcquireMutex at /home/lucas/Projects/RemoteIO/build/../esp-idf/components/freertos/xtensa/include/freertos/portmacro.h:202
 (inlined by) vPortEnterCritical at /home/lucas/Projects/RemoteIO/build/../esp-idf/components/freertos/xtensa/port.c:394

0x4008e974: xQueueGenericReceive at /home/lucas/Projects/RemoteIO/build/../esp-idf/components/freertos/queue.c:1461 (discriminator 4)

0x400d9606: Itc::Wait(void*, void*, unsigned int) at /home/lucas/Projects/RemoteIO/build/../main/Source/Itc.cpp:69

0x400da59d: NetworkTask::MainTask() at /home/lucas/Projects/RemoteIO/build/../main/Tasks/NetworkTask.cpp:55

0x400da609: taskBouncer(void*) at /home/lucas/Projects/RemoteIO/build/../main/Tasks/NetworkTask.cpp:13

0x4008daad: vPortTaskWrapper at /home/lucas/Projects/RemoteIO/build/../esp-idf/components/freertos/xtensa/port.c:143

this 0x400da600

This looks very odd, because 0x400dxxxx is an address in IROM (program code in Flash). Normally a this pointer should be allocated on the heap, so the address would be somewhere in the 0x3ffxxxxx range.
Please check how Itc::Wait is called — make sure that the valid this pointer is used.
If you enable the GDB stub in menuconfig, you can then run bt (backtrace) command in GDB, and it will show you the backtrace along with arguments passed at each level of the call stack (as long as they are not optimized out).

Thank you so much for the help. As soon as you mentioned this "this" pointer being invalid, it immediately jogged my memory about when I've encountered this a few years ago. Found the issue. In order to manage the freertos task in C++, I pass "this" into xTaskCreate, and then have the C function cast (void *params) to my task class and call the task member function.
However, (must have been an accidental accepting of an intellisense suggestion in VSCode) I accidentally passed a random function into xTaskCreate instead of this. Thanks again, and that rule-of-thumb persists: It's never the toolchain's fault


Possible boxing problem

Source

If it late -> close it.
If no, please explane not understand ur idea


[FIX] Switch to delivery_carrier API method

Switch to delivery_carrier API method instead of an old deprecated cart's method to get carrier list on cart page.

@sebastienbeau can you check the "delivery_carrier" method name ? currently it has no plural form while other API methods that return multiple use a plural form.

@thibaultrey I am fixing this here : https://github.com/shopinvader/odoo-shopinvader/pull/634


Now works with webpack 2.x

Your readme says "This plugin uses its built-in loader to extract text from files that end in 'i81n.json' and export them into the destination directory, collated by locale."
This is no longer the case, is it?

The default file extension has changed, if that is what you are saying.

Yes, that's all I meant


adding in status page to our release notes page based on feedback

Description of the change: adding in SendGrid operational status link
Reason for the change: Because people might end up on our release notes if there's an outage
Link to original source: https://sendgrid.com/docs/release_notes.html

Closes #

Hello @ksigler7,Thanks again for the PR! We appreciate your contribution and look forward to                                              continued collaboration. Thanks!                                             Team SendGrid DX


Link to be opened in new tab

The websites linked in the program section are opening in the same page, over the opensource-buddy window, it would be better if they open in a new tab. Assign me this one.

Sure that would be great.

I have assigned this to you @Bishnukt

I have assigned this to you @Bishnukt

Thank u ❤ @AmanSarraf


refactor: store version as a string

Description

Store auth model version as a string in storage
Validate is now a standalone function
typesystem.New now just takes an AuthorizationModel
ReadAuthorizationModel added to cache backend

References

Review Checklist

[ ] I have clicked on "allow edits by maintainers".
[ ] I have added documentation for new/changed functionality in this PR or in a PR to openfga.dev [Provide a link to any relevant PRs in the references section above]
[ ] The correct base branch is being used, if not main
[ ] I have added tests to validate that the change in functionality is working as expected

Codecov Report
Base: 82.00% // Head: 81.88% // Decreases project coverage by -0.11% :warning:

Coverage data is based on head (d61b259) compared to base (c5ba728).
Patch coverage: 87.50% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #257      +/-   ##
==========================================
- Coverage   82.00%   81.88%   -0.12%
==========================================
  Files          81       81
  Lines       10768    10771       +3
==========================================
- Hits         8830     8820      -10
- Misses       1599     1608       +9
- Partials      339      343       +4

Impacted Files
Coverage Δ

server/errors/errors.go
78.75% <ø> (-1.25%)
:arrow_down:

storage/caching/caching.go
63.63% <57.14%> (-4.79%)
:arrow_down:

server/commands/write_authzmodel.go
80.00% <88.88%> (+1.95%)
:arrow_up:

pkg/typesystem/typesystem.go
93.30% <94.87%> (-0.73%)
:arrow_down:

server/commands/write.go
94.48% <100.00%> (+2.82%)
:arrow_up:

server/test/write_authzmodel.go
100.00% <100.00%> (ø)

storage/postgres/postgres.go
65.81% <100.00%> (-0.21%)
:arrow_down:

server/commands/check.go
85.83% <0.00%> (-1.95%)
:arrow_down:

server/commands/check_utils.go
93.27% <0.00%> (-1.27%)
:arrow_down:

... and 4 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.