unable to clear custom query client cache

Describe the bug
I implemented a custom query client in my refine application trying to clear react query cache when I switch from a user to another on sign out.
I extracted query client from useQueryClient hook and i called the queryClient.clear() but it didn't work at all with no errors or feedback.
Steps To Reproduce

install react-query library
create queryClient instance from react-query
wrap refine tag with query client provider and update the options in refine

<QueryClientProvider client={queryClient}>
<Refine options={{
reactQuery: {
clientConfig: queryClient
}
}}>
</Refine>
</QueryClientProvider>

useQueryClient in any component to get the queryClient instance.
create a button and call queryClient.clear()
cache is not cleared

Expected behavior
queryClient.clear() should clear react query cache
Screenshot
No response
Desktop
List of packages:
"@ant-design/icons": "^5.0.1",
"@refinedev/antd": "^5.37.2",
"@refinedev/cli": "^2.7.4",
"@refinedev/core": "^4.32.0",
"@refinedev/devtools": "^1.1.30",
"@refinedev/inferencer": "^4.5.17",
"@refinedev/kbar": "^1.3.5",
"@refinedev/nextjs-router": "^5.5.5",
"@refinedev/simple-rest": "^5.0.1",
"@refinedev/supabase": "^5.7.5",
"@supabase/supabase-js": "^2.7.0",
"@tanstack/react-query": "^5.17.9",
"@tinymce/tinymce-react": "^4.3.0",
"antd": "5.8.1",
"antd-img-crop": "^4.18.0",
"clipboard-polyfill": "^2.8.5",
"next": "^13.5.1",
"nextjs-cors": "^2.1.2",
"nookies": "^2.5.2",
"react": "^18.0.0",
"react-animated-css": "^1.2.1",
"react-dom": "^18.0.0",
"react-markdown": "^9.0.1",
"react-phone-input-2": "^2.15.1",
"react-transition-group": "^4.4.5",
"sass": "^1.64.2",
"supertokens-auth-react": "^0.35.4",
"supertokens-web-js": "^0.8.0",
"tinymce": "^6.7.0",
"tus-js-client": "^3.1.1"
browser: chrome
Mobile
No response
Additional Context
No response

Hello @rawadnasr, can you provide us a reproducible example?
You can use this codesandbox or repo as a base.

Hello @alicanerdurmaz, I used codesandox as a base. Kindly find the reproduced example.
Refine devtools is not working for me ( we can detect from there if cache is cleared or not if it worked ) in the example but I showed the case in the console, I printed the data showing that it's not cleared .
I added a button in the posts listing to clear the react query cache.

@rawadnasr Thanks, I will debug and return you

@rawadnasr Hello again, Thanks for the detailed explanation.
Refine is currently compatible with the "@tanstack/react-query@4x" version. You used @5.
I downgraded to @4 and observed that it works fine.
We have an update to @5 in our backlog, but I can't give a deadline for it right now. You can open an Issue if you want to speed things up.
Also, you don't need a new query <QueryClientProvider /> or a new QueryClient. you can directly use useQueryClient without this boilerplate. If you want to create your own QueryClient, please don't wrap it with <QueryClientProvider />. Refine already wraps the project with <QueryClientProvider />, which may produce bugs.
please let me know if the problem still persists after downgrading to version @4

@alicanerdurmaz Hello, thank you for the support.
I installed  @tanstack/react-query version 4.36.1.
I tried to remove <QueryClientProvider/>, but I faced this issue Error: No QueryClient set, use QueryClientProvider to set one when i used useQueryClient inside the application, it can't be imported from refine so I needed to install react query to achieve this. In additional to that I also tried with the  <QueryClientProvider/> but I couldn't clear the query cache. Does refine provide a solution to clear cache instead of installing react query and clearing it the way we already implemented?? what is the exact version that you installed and worked for you? and how you are using useQueryClient without wrapping the application with  <QueryClientProvider/>??


docs: Add bharathpalavalli.com to the showcase

Created a personal website
Adding website to showcase

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.bharathmp seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Not sure if we should add single-page websites with three paragraphs of text to the Hugo showcase. I don't think such sites are reflective of the possibilities and features that Hugo offers. Might even be off-putting to people considering Hugo.

Adding website design to Hugo-Showcase as suggested by the docs

Hello @bmp,
thank you for adding your website to the showcase of Hugo. Please make sure that your pull requests doesn't accidently contains other commits / changes that aren't part of the showcase addition.

Hello, @digitalcraftsman
I have only modified the Showcase folder as suggested in the docs available at https://www.gohugo.io/community/contributing/#showcase-additions. Please do let me know if you there is something extra or missing and I'll try and make those changes.

The description for the showcase addition should be bullet-proof. You included somehow older commits that aren't related. Nonetheless, depending on you knowledge of Git it would be the easiest to do the following:

Create a new branch with git checkout branch showcase2
Copy the YAML file that you filed out as well as the screenshot of your website and save that at the locations named in the guide
Add the YAML file and screenshot both via git add path/to/file.yaml
Check with git status which files are tracked (those are highlighted green)
Make sure only your YAML file and screenshot are highlighted green
Create a new commit with git commit -m"docs: Add bharathpalavalli.com to the showcase"
Overwrite the commits that are currently mixed. You can use your new commit by overwriting the old one as follows: git push --force --set-url origin bharathpalavalli-sc

Hello @digitalcraftsman,
Thanks, I followed your instructions, and had a bit of a problem with,
git checkout branch showcase2
I am guessing you meant create a new branch showcase2 and checkout the branch. I did the same thing using,
git checkout -b showcase-addition
I then followed the guidelines at https://www.gohugo.io/community/contributing/#showcase-additions, to create the new post,
hugo new showcase/bharathpalavalli.com.md
I then followed your steps to add the .md file and the image,
git add content/showcase/bharathpalavalli.com.md static/img/bharathpalavalli-tn.png
After which I committed them with,
git commit -m "docs: Add bharathpalavalli.com to the showcase"
I had problems with git push --force --set-url origin bharathpalavalli-sc. Again, I am guessing you meant push the changes in the showcase branch to bharathpalavalli-sc. Therefore I had to follow these steps,
git checkout bharathpalavalli-sc
git merge showcase-addition
git push origin bharathpalavalli-sc

I am guessing you meant create a new branch showcase2 and checkout the branch. I did that with,
git checkout -b showcase-addition

You're correct.

I had problems with git push --force --set-url origin bharathpalavalli-sc. Again, I am guessing you meant push the changes in the showcase branch to bharathpalavalli-sc.

git push --force should allow you to overwrite the commit history of the branch on GitHub. --set-url's intended usecase was that the new branch showcase2 should track the remote branch bharathpalavalli-sc which is used for this PR. I.e.
Nonetheless, I merged your addition in c62220d3.

Nonetheless, I merged your addition in c62220d.

Thank you.


Update bulkrax to pull in migration fix

Ref:

https://github.com/samvera-labs/bulkrax/pull/862

I am cutting a new release of bulkrax instead and updating hyku. A follow up PR will reflect this instead.


Adds a few words on using the correct Hugo version

oh, we should just make it work on latest hugo

Should. But not sure when we'll have time. Until then -- is this a good stop-gap?

No, I'll fix it next week. It should not be horribly difficult.

Overtaken by #30 . Closing.


Deprecate in favor of project manager

A lot of time has past and Project Manager (what I based this project on) now has most of the functionality of this package (including usage of atom-project-util which contains the project in-window switch by myself).
I'm seeing tons of issues crop up of this package not working for various reasons and while it still happily works on my machine (insert amusing "works here" comment) I'm not seeing a reason to not officially deprecate this package.
Thoughts?
If you're actively using this package, would you see if project-manager can satisfy how you use project-plus ?

Indeed I had not seen how much progress the Project Manager's settings had done.
I guess it does pretty much everything Project Plus does and has much more users.
Thanks for all the work done on this plugin and for the Atom users! ❤

I thought the empty tree problem was something wrong in project-plus, so I switched to project-manager today to see if the empty tree problem was fixed and it was not. Seems to be an atom thing. But in doing so I see how much progress has been made on project-manager. It seems to fulfill all the needs of a project management package.
It looks like project-plus may not be needed with all of the functionality that is in project-manager. Thank you for all the great work on project-plus.

Same feeling here. However I downgraded back to 1.16 due to this bug.
(If you stick with 1.17, note that a workaround is to open the project in a new window (Shift+enter))

Agreed. I now use Project Manager. Thank you :)

Going to close this issues in favor of https://github.com/danielbrodin/atom-project-manager/issues/345


Replacing NodeJS text with Javascript

Overall, looks good. To reduce risk, I'd recommend backing out the changes to queue names in function.json. It's fine to have "node" there.


3270 emulator configuration

Find a good configuration for wc3270 to enable :

Full size screen
PF keys
copy/paste

http://x3270.bgp.nu/Windows/wc3270-man.html


Updates for Python 3.11 and other breakages, replaces #1826

Cleaned up the history from #1826, this should be ready for merge with rebase.

🎉

🥳


Consolidate submission details

#539
#582
Changes are focused in submission/details

Remove old sections: repositories, manuscript IDs, deposits, external repositories
New display section added intended to consolidate information about repositories, repositoryCopies, and deposits. See ticket for specs

Tooltips have been updated. Code should be a bit cleaner.

Header fonts also updated


Zotero plugin: refresh moves view around

I am using the Zotero plugin version 1.0.3 in Onlyoffice Desktop Editors version <IP_ADDRESS> (flatpak), on Linux Pop!_OS 22.04 LTS.
When clicking the "refresh" button, the view in the document jumps around to the place of the last reference in the document. This creates a big annoyance when adding more references, because the citations auto-refresh, and then I have to find back the place in the document where I was working.
Can the "refresh" action be made not to move the view around? Or, alternatively, can the "insert citation" button not automatically refresh all citations?

Hello! @a-difabio
I have issued this enhancement as Bug #66873.
Thanks for your report!

I have the same issue with my version and it makes working with it very cumbersome.
OS: Ubuntu 22.04
ONLYOFFICE Desktop Editors ver. <IP_ADDRESS>


Fixes alignment issue in static control example

Fix #17195. Replaced control-label with form-control-label class which
is new in v4.

Fixed in #17359.


React primitives: Layout + dimensions

closes #43 and #45

[x] update @hocs/with-resize-observer-props
[ ] smart build for CJS, ESM and RN (and borrow it to @hocs)
[ ] create @hocs/with-view-dimension-props or something like this

Codecov Report

Merging #44 into master will decrease coverage by 4.37%.
The diff coverage is 6.66%.

@@            Coverage Diff             @@
##           master      #44      +/-   ##
==========================================
- Coverage   68.52%   64.15%   -4.38%
==========================================
  Files          12       14       +2
  Lines         197      212      +15
==========================================
+ Hits          135      136       +1
- Misses         62       76      +14

Impacted Files
Coverage Δ

...ckages/react-primitives/src/Layout/index.native.js
0% <0%> (ø)

packages/react-primitives/src/Layout/index.js
33.33% <33.33%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b83cce6...62ed7f6. Read the comment docs.

$ tree packages/react-primitives/build

packages/react-primitives/build
├── browser-cjs
│   ├── Layout
│   │   ├── index.js
│   │   └── index.native.js
│   └── index.js
├── browser-esm
│   ├── Layout
│   │   ├── index.js
│   │   └── index.native.js
│   └── index.js
├── rn
│   ├── Layout
│   │   ├── index.js
│   │   └── index.native.js
│   └── index.js
├── server-cjs
│   ├── Layout
│   │   ├── index.js
│   │   └── index.native.js
│   └── index.js
└── server-esm
    ├── Layout
    │   ├── index.js
    │   └── index.native.js
    └── index.js

all builds are made with different babel configs ❤
TODO:

remove *.native.js from server and browser builds
remove non-native *.js from RN builds if there are *.native.js

@xaviervia I'd like to separate web and native via packages even for primitives, like react-primitives package is a composition of react-primitive-web and react-primitive-native packages. although at first it might look like an additional complexity, I see some benefits:

no need to include/exclude *.native.js files and filter any folder trying to split them into different build folders, web and native packages are truly separated
modularity and composition of packages are just sounds cool, and index.js / index.native.js approach is kinda mixins or something 🙈
no extra downloads if you need only one platform (probably in most cases for web developers)

WDYT? 🤔

Yes. Absolutely. The universal entrypoint should be only the outermost package.


Nuke the svm-common crate

The current svm-common crate has almost nothing left inside.
All the functionality it originally had, has incrementally moved into different places (mainly to the svm-types crate).
The remaining code could be probably moved to a different target.
Another alternative is to rename the crate to a have more meaningful name. (the term common doesn't tell much)

I've thought about this and I actually like the idea of a svm-common crate where, rather than removing stuff, we can dump small utility functions that might get called from multiple crates. At the moment, we only have fmt_hex, which I personally would replace with a real serialization format like Base16, which of course doesn't have commas but has the benefit of being a standard.
What we can do:

Keep the svm-common crate (as in "common utilities").
Rename svm-common to svm-utils.
Nuke it altogether and use Base16 (either with format!() or using hex or any other crate).

I think I would go for (3) given the chance but I'm quite neutral, @YaronWittenstein it's your choice.

I prefer (3) as well. I agree that sometimes utils is a good, but right now it seems it's only about formatting


Vm/VMSS: Managed Disk Integration

@tjprescott, please review. And again, thanks for the improvement on the template scaffolding.

@tjprescott, could you take another look. For design related issue, we have separate threads going on, and I will also chat with CRP folks in 'doc update' meeting today. But i would like to get rest addressed.


Update Interaction_Example.R

Added plots to this example.

Can you approve this? I think it got skipped a few months ago.


Add cfg to setup.py

Add cfg to setup.py. This resolves an error encountered in #71.

@chengzhuzhang Let me know if I should just merge this. Should we wait to release an rc3 in case any other issues come up in testing?


Post release automated changes for core releases

Post release automated changes for azure-core-http

API change check
API changes are not detected in this pull request.


Upgrage cartodb extension to 0.18.5

New extension revision with some fixes and two new overview strategies.

LGTM

:+1:


Switch to Addressable::URI for URI parsing

Using Addressable::URI would allow spidr to handle IDN domains.

Hello, could I help with this feature?


Possible to add zones? [REQ]

Many sprinkler systems incorporate zones. These areas are often fitted with different numbers of sprinklers with different flow rates and watering times would be different for them. Any possibility of expanding this to offer the option for multiple zones? If I'm looking at this incorrectly, please let me know. I love the idea, just not sure how it fits my system.

Zone support is already there, just add the component multiple times. I will document this further

You can add the integration multiple times; one for each zone you have. That is how I use it.

or you can have a look at my config: https://github.com/ciechompl/HA-yamls/tree/master/Smart Irrigation
I also have several zones (currently 8) and to fully control how much water each zone should get :) I added several input_number sliders where I can tune irrigation time  (% wise) calculated by this component. The main thing is that first you have to calculate average water flow for entire system and doesn't matter whether you define 1 big sprinkler or e.g. 8 sprinklers in the component where each will represent one string of sprinklers. component will calculate irrigation time for entire garden and later you cna use it in automation to run one string after another .... At least for me it is perfectly ok so maybe you will also get inspired how to implement component in your system :)

I had actually just thought about trying to do this. Was coming back to let you know I figured it out. :-)

Awesome, let us know how you get on!

Just need to figure out how to use it with what I already have. I'm sure I'll have to rewrite a bit, but that's how it usually goes.

I'm not sure I understand how this thing is supposed to work. Right now it's got my daily adjusted run time for one zone at over half a day. It's been raining on and off for the past two days....

Can you share screenshots of sensors and attributes as well as if you have HA configured in metric or imperial system?

I am in the US and everything should be imperial. Hopefully the pictures come through. The first is the sensors overall.

Unless I'm reading into how this is supposed to work, It's telling me I need to run that zone for nearly 4 hours. I know I probably need to adjust the parameters on the zone a little, but it's pretty close I believe. Was just running it along side my routine to see how it worked before I integrated it. After all, it's modeled after a very successful watering models. I hope I'm just looking at something wrong and didn't find a big bug...

right, this doesn't look good. somehow your bucket is way off: -3.7 inch, while it should have been .3 inch assuming this is the first 24 hour you run this. Can you call the reset_bucket service and monitor again what it does at 11PM tonight?

Sure. I had reset the buckets yesterday just to be sure I knew how to do it. I'll do it again right now, but it's still drizzling so I don't know how that's going to play into things. I'll post zone 1 before and after reset...

After reset...

Resetting it returned everything to zero as expected. Will let you know what I have tomorrow...

Yeah, just bear in mind that the change percentage behavior has changed so if you get massive percentage reported in the attributes of daily ART go to options and click OK. That should set it to 100 or to whatever you want it to. Given what I see now we should expect the bucket to be set to approx 0.17 inch at 11pm. It is set to the average of the collected netto precipitation. So if it is way off from that something is off.

No problem. I went back and read how to use it several times and figured something had to be wrong somewhere. There's no way it should be telling me to water anything. We've got standing water in the yard now...

right, the netto precipitation>0, so that means more moisture is added than removed, so no need for irrigation. at 11 PM you should see your bucket being updated from 0 to whatever the average netto precipitation is (let's assuming 0.17 for now). Given that bucket>=0, your daily ART is going to 0, which means, no need for irrigation. Your bucket will not be reset however.
If the next day your netto precipitation is still > 0, the same will happen, but of course the bucket is not 0, but 0.17 to begin with. Let's say the netto precipitation is 0.13. The bucket should end up at 0.30 then. Now, imagine the day after that there is no rain and a lot of sunshine. Your netto precipitation might be -0.35. You should see your bucket dropping to 0.30-0.35=-0.05. That would bring your daily ART to something above 0, which should prompt you to irrigate and most importantly, sequentially reset the bucket to 0. (you have to set up an automation yourself). I hope this clarifies a bit on how it is supposed to work. Now let's monitor and see if there are any bugs. Your set up looks good now, so don't touch anything but keep an eye on the values and see if you see the same pattern as I explained above happening.
In the mean time, I will think about adding some visual explanation of this to the documentation.

@MYeager1967 - I created this page in the Wiki - hope this helps: https://github.com/jeroenterheerdt/HAsmartirrigation/wiki/Example-behavior-in-a-week

I was pretty certain that I understood how it was supposed to work. I had even ready the Rainbird pages on it. That's why I couldn't understand why it was suddenly wanting me to water for HOURS, not even just minutes. Was the bump in version to correct something that was causing the issue? I'll let you know tomorrow if the numbers look good. Once this is all sorted out, can I change the time for the daily update? I generally water about 8pm. Otherwise I'd be watering about 8:30am and the sun is already up...

Ok. Here's what I have now for the same two sensors I zero'd yesterday.

At this point, it appears to me as though the precipitation total for the day isn't getting updated. It looks as though it's getting replaced by the new value instead. I also can't figure out where the evapotranspiration number came from. At .21, I would figure that to be a hot, possibly windy day here (the data input was something like .17 or so for June) and it was overcast and rainy. If it would help to look at the data provided, I'm using all OWM data and my zip code is 34743.

Your change percentage is way off. Go into options and make sure it says a 100 there and save the options. Change percentage should turn to 100 in the attributes of daily ART as well.

Is there a way to go back and change settings without a remove and reinstall? I am using my own weather station and believe I chose the wrong sensor for rain logging

It was already 100 but I saved it anyhow and now it reads 100 in the sensor. in about 20 minutes, I'll get the next hourly update and we'll see what changes then. Rolling back to v0.0.29....

@MYeager1967 thanks, keep me posted.
@WizShip no, unfortunately. Also, please do not hijack threads. Open a new issue.

I don't see any problems with daily runtime. However it's raining all day here so it will be about 0 today:-)

Of course now that I've rolled the version back, the sun has peeped out. Not going to be very helpful to tracking down and issue with the bucket, is it?

Apologies :-( But to be fair the thread is about adding zones and not about buckets either :-) Regardless...not worries

@MYeager1967 should be fine regardless. just take note of the current bucket value and the netto precipitation during the day. We should see the bucket being updated with the average of the netto precipitation.

If it rains any more today... What made you suspect an error in the way it was being updated?

@MYeager1967 on the community forum (community.home-assistant.io) people have been complaining about the latest release as well, that's why :)

Is the precipitation supposed to keep a running total or change up and down every hour? There has to be a running total for the day somewhere???

No worries, the running total is kept by the system. When it calculates daily values you will see in logs that it takes the average of the the hourly values.

This is what I have this morning

Looks much better but I still don't understand why the hourly updates jump all over the place. Doesn't matter I suppose as that's not what controls things. You say the running total is kept by the system. Will it survive a reboot? As you know, HA gets updated frequently at this point. Good for us as it's generally new features as well as a few bug fixes, bad for data if it's not retained during reboot. Any luck chasing down the issue with the new version yet?

If you restart HA hourly runtime will "jump all over the place" as it will be 0 after restart. The daily runtime will persist. So if you don't restart HA hourly runtime will be smooth:-) Hourly is not persisted but updated after 300 seconds when HA started.

Ok. I have been working on it quite a bit lately so that may account for why is does what it does. At the end of the day, the hourly adjusted run time isn't what controls the show, so it really doesn't matter. I just like to understand how things work, not always possible though. :-) Now it's time to settle back and watch it work for a while. I see it updated the bucket. We got a ton of rain yesterday....

Happy to see that it works the way it's supposed to now. I am seriously considering pulling every release since the one you are running now since somewhere along the way of introducing new features it broke. I have a - 0.11 bucket and my ART is over 3000 minutes with the latest release. Also getting reports of the same through other forums. Hope to get some time soon to investigate.

Yeah, that's what I saw on the later release as well. It was going absolutely nuts...
I'm looking forward to putting this to use after I see how it runs alongside my current system.

ok, v0.0.40 is out - change percentage is disabled since it caused so many bugs (sorry @ciechompl ...). Initial update delay is still there since it does not seem related. Also, all bug fixes since v0.0.29 are included as well. Please update and test :) Thanks for bearing with me!

I'm not sure the percentage of change was important anyhow, was it? It likely just caused confusion....

well, it certainly confused me ;)

Does the evapotranspiration figure change frequently depending on the OW data or should that stay fairly constant?

IMHO, percentage shouldn't be part of this plugin; it's purpose is calculating daily runtime. If someone want's to alter the calculated values he can do so in various ways within HA.

Only alteration I'd likely make is a maximum runtime in case something got screwed up. The whole reason for this is to provide a proper watering time...

@posixx I tend to agree that percentage does not need to be part of this component.
@MYeager1967 evapotranspiration is calculated every hour and can change, depending on sun hours or wind speed for example. Many factors impact it. Also, maximum runtime is already implemented and available in the options screen.

Yes it is... That would prevent these 15000 second run times in case of an error. So long as something realistic is in there, it should limit it to the max run time.

@MYeager1967 - right, so by default if you go into the options screen you will see the max duration set to -1, which means there is no maximum. Personally I have it set to 1800 seconds (30 minutes)

I'm redoing my sprinkler routine as we speak. I don't do automations in HA, I do them in Appdaemon instead where I have full use of python. Not sure I have a need of forcing the sprinklers to run, but I'll keep it in mind and have something clear the forced flag after each run. That way, a simple switch can be set to set all zones to run manually and once they run, it can be cleared automatically. Is that the basic idea behind it?

Yes sir. Please share whatever you create, so I can include it in the examples!

May still have a problem. Pretty certain I didn't go from 1 inch to this in a day....

That is weird. Did you reset the bucket at all? What was the value before? And what is your netto precipitation for today?

Hasn't updated yet this hour...

Running v0.0.41 here my daily runtime also was 0 last night:

Although hourly runtime seems good:

Went to roll back to 0.29 this morning, but it wasn't in the list of options. :-)

@posixx the bucket is > 0 so no Daily ART is expected to be 0. Did your bucket decrease with 3.9 (netto precipitation)?

Sorry jeroen i don't know. Didn't look at these values at all.

I've got one zone that I zero'd the bucket on last night to see what the result was today compared to the other two zones that gained 30 inches in the bucket yesterday. Needless to say, we didn't get 30 inches of rain yesterday or I'd be sending this from a boat...

@posixx right, so that seems OK. you are running version 0.0.41 right? Just think of bucket as an actual bucket - when there's water in the bucket (bucket>0) you do not need to irrigate. When the amount of water in the bucket becomes negative (this is where the bucket analogy breaks) you should really add water to the bucket so it is exactly 0 (bucket is empty, no water inside, but also no water 'mising'). That is what you do by irrigating for exactly the daily ART amount of time. Afterwards you tell the bucket to reset to 0 since you added enough moisture. Hope that helps.
@MYeager1967 - please let me know which version you are running on right now. are you still having problems with the zone that you zero'd or does it look OK now? If so, please update to the latest version if not already on that and reset both the buckets for the other zones.

As far as I know, I'm running the latest (0.41). I zero'd the bucket for zone 3 and am waiting to see what the day does to it when it updates tonight. I'm also curious to see how much the other two zones change but 3 is the real test as it started at 0. At the moment, all three zones are in line with each other for the hourly adjusted figures. Doesn't mean much for the daily though...

Wow. My bucket for zone 1 went from 30 inches yesterday morning to 769 this morning. Now, that zone was already screwed from whatever the error was the other day.
Zone 3, which I had zero'd as noted in an earlier post here, now shows .08 which I'm not sure is correct as we had quite a bit of rain yesterday, but at least it didn't go up astronomically. Still not certain how these numbers are figured as, in the picture below, you can see the ET number.

That is way higher than I would expect it to be with the cloud cover that we have today. I'm assuming, however, that this number is achieved from data obtained by OW and the fixed ET data entered at startup. I know it changes throughout the day. I'm also assuming that the +/- net rainfall is tracked throughout the day as that should be the value that goes into the bucket.
I do enough programming to appreciate the time that you've got in this and how easily a small error one place can screw everything down the line. I can only imagine the amount of time you have invested in this and the research that's gone into putting this together.
Thank you once gain for your effort!

So the bucket looks fine to me now. Evapotranspiration is based on OWM data, and calculated using the pyeto library. The documentation for pyeto is limited. The code that calculates evapotranspiration is here: https://github.com/jeroenterheerdt/HAsmartirrigation/blob/master/custom_components/smart_irrigation/sensor.py#L613, feel free to check it. I did, but there might be issues in it.

Is there any value in the hourly update that's guaranteed to change every hour? I'm guessing the ET value, but it's only a guess. I'm setting up a monitor to observe this process for a few days. External error checking as well as a better understanding of what is going on.

there is no guarantee, but you would probably see netto precipitation change and as a result the hourly adjusted run time itself since it is based on it. You would probably also see precipitation and ET change during the day, unless you have very static weather patterns.

Would it be possible to lock the hourly updates to a certain time window or record the previous update time to ensure that it only updates once an hour? If someone is working on their HA installation and reboots several times, it's very likely that it screws the calculations for the day.

I don't think that would be an issue as I am taking an average of the measurements when calculating the daily value... so it does not matter if you take measurements every 5 minutes (other than it being way too much ;)).

@MYeager1967 just passing this along since you are in the US just like me - I have installed the Smart Weather custom component, they had two stations very close to me. I am now running a full Open Weather Map based version and a Smart Weather sensors based version side by side (with min/max temperature still from Open Weather Map). So far, things look way better. This should do fine for me until I built my own weather station.

I'll look into that. May have my own thing going but I haven't dug into what sensors Smart Irrigation needs yet. I'm looking into Climacell and so far, it's almost dead on with DarkSky. Has a lot of extra data if you want it as well. I'll look into Smart Weather to see what they have in my area.

If I wanted to control the time that the daily update occurs for zone 1, I'd use the smart_irrigation.zone_1_calculate_daily_adjusted_run_time service, correct? I'm assuming that this is the only one that's deactivated by turning off the automatic update and that the hourly still runs roughly every hour?

Hey  jeroenterheerdt, thanks for putting this together. If you use the "work days" condition approach, and only want to irrigate, say, 4 days a week, will the adjusted run times continue to build up and irrigate for an appropriate amount of time when it does trigger a cycle? I'm trying to wrap my head around this. I've plugged in all my data and my BSI minutes is showing 31.17 minutes. I assume this means at peak ET, i should be watering for 31 minutes each day. If i irrigate every other day, would my sprinkler run for ~ 60 minutes (assuming 2 days of peak ET in a row)?

Also, are the calculations dialed in for turf irrigation only? Would using this integration on zones with shrubs/flowers/etc be overkill and potentially lead to overwatering?

I haven't full;y figured out the program yet, but the adjusted daily run time would likely build up to whatever the maximum run time that you set. I have been playing with this for a week and am just now confident enough with my weather information to go live with it (this morning would have been the first run). As for the shrubs, they usually require more water than just grass, but if they're on a zone of their own, you can set a maximum watering time and adjust that as you feel the need (or keep playing with the zone information until you get it where you want it).

Ok, possible issue. I pointed the rain sensor at a value that tracks accumulated rain for the day. It appears as though the program looked at it every hour and added it all up to give me a 3.59 inch bucket this morning. Shouldn't the accumulated rain for the day only be looked at once (probably at the daily adjustment time)?

@MYeager1967 yeah, I noticed that behavior as well. I am working through the details now.

@stephenmetzger I am no botanist at all, but this component just calculates the amount of moisture lost and how long the system needs to run to make up for the lost moisture. if that's how you want to water your shrubs or whatever then it is all good. there are no specific optimizations for lawns.

Just so you know, My weather source seems to start out with an estimate early in the day and winds it down as rainfall accumulates. Today, I have had zero in it all day, as it's not even supposed to rain. It updates every hour (or at least that's when I update it).

Thanks @jeroenterheerdt and @MYeager1967. Does manually calling the "calculate daily" service mess up the integrations running calculations? My hourly adjusted times seem to be updating nicely, but my daily adjusted time has been at 0 since 5PM yesterday. I've been trying my best not to touch anything and just check in on how it changes throughout the day, but it's a slow way to tinker around and figure out how it all works.

You can always reset the bucket(s) after you're done playing. What time is your daily adjusted supposed to run? It only runs once a day and I believe it's set by default to 11pm. If you really want to figure out how it works, read the wiki and then do a little more research on your own. Watching it work will confuse you...

as @MYeager1967 said above, by default daily adjusted run time is only updated at 23:00 local time, once a day. so it being zero makes total sense until that moment comes. as you can see in the wiki / readme, the value stay zero even after the update happened in case the bucket >=0.

Yeah, ive read and re-read through the wiki, super good information, just trying to ground-truth it all.
I expected an update at 11PM last night, but didnt see anything update.

I was guestimating on my sprinkler flow rates on first setup, and was using the BSI minutes to confirm things looked about right. I think I made my last change (re-install) at around 5 yesterday, and let it run (not connected to any actual sprinklers) without touching it. Checked a little after 11:00 and didnt see any changes to the daily adjusted. I'll continue to let it run all day today (high heat and no rain) and see what happens tonight at 11.

Also, bucket reset resets the bucket for all iterations of the integration, right? So, you can re-set the bucked for individual zones?

@stephenmetzger if you have multiple instances of the component enabled then you will see multiple reset_bucket services. that's your answer: everything happens in context of the instance so yes, you can reset the bucket for individual zones

Ahh, I see it now. Hadn't checked back in the services tab since I resintalled and added second zone. Thanks!

Watch your hourly adjusted run times and it'll freak you out, but you'll know that something is happening. The daily tonight should reflect it.

I'm going to take it that the update yesterday was to address the exponential growth in the bucket? I went from a 3.59 bucket yesterday to an 84 today with zero on the rain counter until 3pm. It was .0025 until 9pm then went to .0197 until 3am, long after the daily run.
Now at 3am, it went to .1389 which I believe to be an estimate of rain expected. It did rain some overnight, but the rain accumulation has dropped to .1009  (at 6am) and remains there now. I suspect it will adjust sometime today to meet up with whatever rainfall we do get. It's supposed to rain.
I reset all my buckets about 8am, so here's to hoping things look better tomorrow....

@MYeager1967 no, I did not do anything to fix the weird spike in the bucket, but I did add a lot of logging to hope and be able to track it down. Please monitor your logs and share anything that looks like an explanation.

I don't see anything in my logs. Would you like me to log something specific? If so, guide me along and I'll do what I can.

in your configuration.yaml set this:
  default: error
  logs:
    custom_components.smart_irrigation: info

Wow, what a mess... That's a LOT of logging. That said, I'm showing an hourly adjusted bucket of -5+ inches and I reset the buckets to 0 this morning. Is the program expecting an hourly rain total or a daily rain total? Should the bucket be touched any time other than the daily update? I can see where the ET value needs to be figured hourly, as the temperature and everything affects it, but adjusting the bucket value hourly seems as though it's going to require a fairly accurate, hourly rainfall total. Also, would it be possible (or useful) to lock the hourly updates to a given time like the daily is? I'm not sure if I'm reading what I think I'm reading, but "Bucket value was: -5.918656797890241" after 9 hours or so can't be right and "just updated hourly_bucket_list: [0.0, 0.0, -5.918656797890241, -5.918656797890241, -5.918656797890241]" is a bit puzzling. I had to do a couple of restarts, so I'm attributing the multiple entries to that. Even at that, it's horribly wrong.

if you use sensors (as you are, I think) it expects a daily rain total (additive sensor), when the daily is updated it will take the most recent value.
daily bucket should not be touched for anything other than the daily updated. The hourly adjusted run time is of course updated every hour.

Please reset your bucket once more. Also confirm if you are running in imperial system or in metric?

I am all sensors and on imperial units. I've learned not to pay much attention to the hourly as it does some crazy things during the day. Just zero'd all the buckets and I see the events triggered by that in the logs. I'll check back either later, or most likely tomorrow sometime, but I suspect the bucket is going to be horribly off again. :-)

I hope it is not :) just make sure you are on the latest version (v0.0.49)

Updating the component was one of the reasons for the reboots...

I have been running this version for two days now (v0.0.49) and it seems much better. No guarantees we're out of the woods though. I am running this on imperial as well. I also have a version running on metric, but the bug never appeared there.

As long as it isn't reading the rain total every hour and adding it together. I can't understand how I keep getting these huge buckets though. Just out of curiosity, why did you make three different entities instead of one with all the attributes under it?

ehh, why? Because there are multiple different calculations going on and I was losing track of all of it. You're right, we do not need to surface the base schedule index nor the hourly entity, but it has proven very useful in debugging with others - now I can just get some screenshots and help right away. In retrospect it could all have been one gigantic entity with lots and lots of attributes but I would feel that would be even more confusing.

That makes sense. Fewer things per entity probably does make things a little easier to track. The "sensor" I am using is a weather service API (ClimaCell) and it seems quite accurate for this area. Problem is, it runs 6am to 6am UTC (2am-2am local currently). It's close enough. Anyhow, it seems to give an estimate for the day, and then adjusts it as the day goes on to somewhat match what actually occurs. It has actually lowered on the days that we didn't get the rain forecasted. It should work out depending on when it actually uses the rain values. I might have to figure out another source of rainfall data if I can't get this one to seem reliable with the component. Once it's all running the way it should be, I'll be hiding everything but the daily run time. Those will show on the sprinkler panel.

Well, so far things are looking quite a bit better. Watching the logs is an exercise in WTF though. I still have all kinds of rain amounts I can't figure out but they appear to be figures from the hourly updates, which I already know will drive me crazy trying to understand them. Today is supposed to be a bit wet later in the day, so we shall see. I came out of yesterday with a .04 bucket, which is probably about right with the rain we had yesterday. It's going to be fun to try to manually get this going after a few days of allowing the extra moisture to dry up. I should probably have a bigger bucket, but I'm sure after some extended tweaking, all will be good. A few more days will be telling...

thanks for letting me know. I am curious to what things you see in the hourly numbers that drive you crazy. this is what I am seeing:
 and it is pretty consistent (ok, couple of spikes yesterday, but to be fair, I was doing reboots at that time). but other than that it seems to follow a pretty nice pattern.

It's just the fact that it changes every hour and doesn't seem to reflect on the daily change. The logs are where the numbers really get interesting but since I don't know how they're generated and used, the end result is what I'm looking at. The hourly adjusted run time sensor is predictable though. Mine follows the same pattern as yours. I've seen it at certain times of the day showing nearly double the base schedule numbers but by the end of the day, things are normal. That's the part that would drive me nuts trying to figure out. I'm guessing that with the hourly weather conditions, it's computing the run time needed if you ran the system right then. It appears to work as it should though, the end of day result looks close to what I expected for yesterday.

Wanted to provide an update. At the first 11 pm update things looked good, the daily adjusted time was at about 30 minutes which seems about right. But, at the second 11pm update, with no bucket reset, my daily adjusted spiked to ~21,000 minutes.
I help off on updating, but will do so not and continue to monitor.

Let me know if you still have issues after updating!

Sorry, used the term "updating" multiple times to refer to two different processes. The "11pm updates" im referring to are the daily sensor update to the daily adjusted run time that happen at 11:00 by default.
I just updated to the latest version of the integration, and my daily adjusted run time has gone down to 845 minutes. Still not great, but better than 21,000 minutes. Should I do a bucket reset?

in case you're interested, I created a Daily Sensor component (https://github.com/jeroenterheerdt/HADailySensor) that can help build a minimum and maximum temperature sensor so you can remove all ties with open weather map or other services if you are using them just to get minimum and maximum temperatures.

@stephenmetzger you should do a bucket reset yes, otherwise this will keep carrying the faulty calculations.

I'm actually looking pretty good on the bucket issue this morning.
I'm getting my minimum and maximum temps for the day the old fashion way, with math. :-) Is that all the new component is doing is tracking the high and low from the actual temps?

Yeah, it is essentially just a statistics sensor with the major difference being it will reset to 0 at 00:00 local time. If you already solved this differently no need to use the component. I was surprised it was not as easy as this so I built the component.

It's a bit surprising that most of the weather providers don't provide the high/low for the day. I'm using AppDaemon for all of my automation and I just put together a quick program to grab the information from ClimaCell. It doesn't give you the high/low either so I just compare the temp to the recorded high/low and go from there. At midnight, I simply set both equal to the current temperature. I want to look into writing it as a custom component, but I know nothing about doing them. Gotta look at others examples and see what I learn.

Why is there a beta version in the HACS registry? I wouldn't think you'd want a beta out for general consumption....

Where does it say beta? I used a and b before as I did minute increments

Oh, Ok. I'm used to seeing a and b used for alpha and beta releases. Sorry.... :-)

I think it is time to close this thread.


Investigate whether cached target client in gardener-resource-manager can be re-enabled

How to categorize this issue?

/area scalability robustness networking
/kind enhancement
What would you like to be added:
With https://github.com/gardener/gardener/pull/3268, we have disabled the cached client (for shoots) in gardener-resource-manager, see https://github.com/gardener/gardener/blob/db8055dcfe2e3b01929a44373e3616e9f7df60c7/cmd/gardener-resource-manager/app/app.go#L217-L221
The reason was https://github.com/gardener-attic/gardener-resource-manager/issues/92.
Can we go back to a cached client for gardener-resource-manager? Technically, we already have a lot of other controllers like kube-controller-manager, cloud-controller-manager, etc. which have watches/caches for the objects in the shoot cluster as well, so there should not be a reason why gardener-resource-manager should be different.
The problem from https://github.com/gardener-attic/gardener-resource-manager/issues/92 is still real, I guess, so maybe we can work with disabling the cache for specific objects (Secrets, ConfigMaps, to start with) by extending https://github.com/gardener/gardener/blob/db8055dcfe2e3b01929a44373e3616e9f7df60c7/cmd/gardener-resource-manager/app/app.go#L223-L227?
Why is this needed:
The uncached client creates some complexity in the code, for example, we have controllers watching objects in the target cluster (https://github.com/gardener/gardener/blob/db8055dcfe2e3b01929a44373e3616e9f7df60c7/pkg/resourcemanager/controller/csrapprover/add.go#L50-L51) but read them with the uncached client in the reconciler (https://github.com/gardener/gardener/blob/db8055dcfe2e3b01929a44373e3616e9f7df60c7/pkg/resourcemanager/controller/csrapprover/reconciler.go#L53).
Also, due to the uncached client, we can't use certain features that we have built into gardener-resource-manager, for example https://github.com/gardener/gardener/blob/db8055dcfe2e3b01929a44373e3616e9f7df60c7/pkg/resourcemanager/controller/health/progressing/add.go#L79.

/assign

We checked the memory usage for gardener-resource-manager running on a seed which hosts 161 shoots. Here are the results:

Target Cache Settings
controller-runtime Version
Memory Usage
Gardener Version

Disabled
0.14
500 MiB
< 1.79

Enabled
0.15
3.5 GiB
1.79.0

Enabled w/o Secrets/ConfigMaps
0.15
1.2 GiB
1.79.1

Enabled only for kube-system, kubernetes-dashboard namespaces
0.15
133 MiB
>= 1.80

With controller-runtime versions < 0.15 it was only possible to restrict the cache to exactly one namespace - now, we can have multiple namespaces. Apart from even reducing the memory usage (it's not really clear why, perhaps there were significant internal improvements with their new minor versions), also the number of GET requests has reduced, causing much faster reconciliations:


Update documentation to reflect removal of inplace option

MCVE Code Sample

# Your code here
ds_gamma.reset_coords('month', drop=True, inplace=True)

~/miniconda3/envs/spi_multi/lib/python3.8/site-packages/xarray/core/utils.py in _check_inplace(inplace)
     38 def _check_inplace(inplace: Optional[bool]) -> None:
     39     if inplace is not None:
---> 40         raise TypeError(
     41             "The `inplace` argument has been removed from xarray. "
     42             "You can achieve an identical effect with python's standard assignment."

TypeError: The `inplace` argument has been removed from xarray. You can achieve an identical effect with python's standard assignment.

Expected Output
Coordinates reset in-place, or documentation that does not list inplace as a valid argument.
Problem Description

The documentation for Dataset.reset_coords and Dataset.reset_coords lists an inplace argument that is no longer supported. My assumption is that this should be removed from the documentation but I'm not sure how this documentation is generated -- it may come from the docstring and/or function signature and the argument is still present in the function signature so it shows up in the documentation as a result?
This appears to have been addressed before in issue #858 but maybe the inplace argument slipped back into the documentation somehow? I see that there is a function to check for an inplace argument and raise an error if present -- why is this being used rather than removing the inplace argument altogether? Is this mechanism in place to facilitate backward compatibility, etc.?
Output of xr.show_versions()

# Paste the output here xr.show_versions() here
INSTALLED VERSIONS
------------------
commit: None
python: 3.8.0 | packaged by conda-forge | (default, Nov 22 2019, 19:11:38)
[GCC 7.3.0]
python-bits: 64
OS: Linux
OS-release: 4.15.0-70-generic
machine: x86_64
processor: x86_64
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: en_US.UTF-8
libhdf5: 1.10.5
libnetcdf: 4.7.1
xarray: 0.14.1
pandas: 0.25.3
numpy: 1.17.3
scipy: 1.3.2
netCDF4: 1.5.3
pydap: None
h5netcdf: None
h5py: None
Nio: None
zarr: None
cftime: <IP_ADDRESS>
nc_time_axis: None
PseudoNetCDF: None
rasterio: None
cfgrib: None
iris: None
bottleneck: None
dask: 2.8.1
distributed: 2.8.1
matplotlib: 3.1.2
cartopy: None
seaborn: None
numbagg: None
setuptools: 42.0.1.post20191125
pip: 19.3.1
conda: None
pytest: None
IPython: 7.10.0
sphinx: None

Thanks for the issue and observation @monocongo
We left the kwarg for a couple versions so that existing users had an informative error message and clear instructions for . We removed it from the docstring.
That said, it's been a couple versions, so would welcome a PR to remove these for v0.15.0


[5.2] pushMiddleware to the "web" middleware group

in previous version 5.1 i was able to push and prepend middleware from serviceprovider boot()
$this->app->make('Illuminate\Contracts\Http\Kernel')->pushMiddleware('App\Http\Middleware\Localizer');
function pushMiddleware($middleware) accepts only one paramater how to pass the group

Groups are not at all the same as global middleware. The groups are attached to the router layer.

$this->app['router']->middlewareGroup('web',[
\App\Http\Middleware\EncryptCookies::class,
\Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
\Illuminate\Session\Middleware\StartSession::class,
\Illuminate\View\Middleware\ShareErrorsFromSession::class,
\App\Http\Middleware\VerifyCsrfToken::class,
                \Custom\Base\Locale\Http\Middleware\languageDetector::class,

            ]);

i can redeclear all the web group like this
but what i need is to push my middleware to the end of Middleware group web in  dynamic way
@GrahamCampbell

@GrahamCampbell


Group projects

@raulraja @rafaparadela there is one problem with adding content here since it requires the sbt-exercise plugin, which is one of the subprojects. I tried adding the compiler plugin only to the subproject but plugins are global to all projects; should we keep content separate? Another alternative is to have it as a subdir in the repository but not as a subproject, and have its own build.sbt. Thoughts?

Let's keep it a separate project since ultimately each lib featured in scala exercises will have it's own project. Inmediately after combining the repos we need to also split content and separate the stdlib, cats and shapeless into independent repos. This will help down the road separate their transitive dependencies so they run in their own classloader to avoid version collisions among libraries and projects they use cats, shapeless , etc....

:+1:, let's make the build green before merging this.

I ignored some ill-behaved tests. Due to having to generate many case classes and discarding a lot of data Scalacheck sometimes ends up failing a property, even after a few successful evaluations. It seems like Scalacheck doesn't respect the Scalacheck config I give it, so i'll convert those tests to plain example-based tests in a future PR.

@raulraja @rafaparadela please take a look and merge at your convenience.

According to our purpose of having multiple projects in this repo again, all these changes look good to me.

@raulraja please take a look.

LGTM


Disable formatting of @fluid-experimental/tree package.json

#4821 introduced a build break caused by incorrect formatting of this package's package.json. This was fixed in #4871.
The break was possible because the PR gating pipeline includes a step which runs lerna version that in turn modifies package.json contents. Lerna appears to conveniently uniformize package.json files as part of that command, which rectifies the incorrect formatting. Thus, when the lint step ran here, it passed the formatting check even though the source commit alone would not have.
The main reason for using a code formatter in this package is to maintain relatively easy automatic merging of files while the changes are integrated between the version in this repository and the one in an internal repository. Since we don't particularly expect merging of package.json to automatically merge correctly in most cases, just adopting the fluid conventions and disabling formatting should work fine.

@Abe27342 I can merge it once the conflict is resolved.

@Abe27342 I can merge it once the conflict is resolved.

Thanks @curtisman. Conflicts should be resolved now.

Thanks @curtisman. Conflicts should be resolved now.


Bugfix client ignoring search time

Codecov Report

Merging #35 (89d658e) into master (5bc867e) will increase coverage by 43.33%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           master      #35       +/-   ##
===========================================
+ Coverage   22.62%   65.96%   +43.33%
===========================================
  Files           9        9
  Lines         663      661        -2
===========================================
+ Hits          150      436      +286
+ Misses        513      225      -288

Impacted Files
Coverage Δ

stixpy/data/test.py
95.23% <ø> (ø)

stixpy/net/client.py
100.00% <100.00%> (+67.64%)
:arrow_up:

stixpy/science.py
57.68% <100.00%> (+39.81%)
:arrow_up:

stixpy/timeseries/quicklook.py
62.90% <100.00%> (+45.79%)
:arrow_up:

stixpy/vis/map_reprojection.py
64.28% <100.00%> (+48.76%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5bc867e...89d658e. Read the comment docs.


Update Proxy 6.5 to TiKV 6.5(2ab52016)

What problem does this PR solve?
Issue Number: close #xxx
Problem Summary:
Origin is https://github.com/pingcap/tidb-engine-ext/commit/874c0a3b63190e82fe05dc1c939312c08afaa199.
What is changed and how it works?
Check List
Tests

[ ] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Documentation

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Changes MySQL compatibility

Release note

None

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.6 out of 14 committers have signed the CLA.:white_check_mark: joccau:white_check_mark: lijie0123:white_check_mark: ti-chi-bot:white_check_mark: HuSharp:white_check_mark: CalvinNeo:white_check_mark: fengou1:x: JmPotato:x: sticnarf:x: MyonKeminta:x: xiongjiwei:x: YuJuncen:x: cfzjywxk:x: BusyJay:x: tabokieYou have signed the CLA already but the status is still pending? Let us recheck it.


[BUG] Register-PnPEntraIDApp never completes

Reporting an Issue or Missing Feature
The command Register-PnPEntraIDApp never finish. I got a warning saying "No permissions specified, using default permissions" and nothing else, no device code webpage, nothing.
Expected behavior
The command should give me a device code that I can use in the device code URL.
Actual behavior
Just a warning saying "No permissions specified, using default permissions". The cmdlet is stuck.
Steps to reproduce behavior
$result = Register-PnPEntraIDApp -ApplicationName "PnP App Only Access" -Tenant xxxx.onmicrosoft.com -OutPath c:\mycertificates -DeviceLogin
What is the version of the Cmdlet module you are running?
2.12.0
Which operating system/environment are you running PnP PowerShell on?

[X] Windows
[ ] Linux
[X] MacOS
[ ] Azure Cloud Shell
[ ] Azure Functions
[ ] Other : please specify

(Tried both, same behavior)

The issue with DeviceLogin is fixed in the nightly builds, can you please try the latest nightly 2.12.4-nightly and let us know ?

Same behavior for me, fixed it by using nightly build 2.12.9

Thanks for confirming @kjellbrandes.
@bcarnazzi - Please update to the nightly. Closing this now.

Hello -- i am running into this issue currently, but when I try to upgrade to 2.12.4-nightly I get this error:
Install-Package: The version '2.12.4' of the module 'PnP.PowerShell' being installed is not catalog signed. Ensure that the version
'2.12.4' of the module 'PnP.PowerShell' has the catalog file 'PnP.PowerShell.cat' and signed with the same publisher
'CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US' as the previously-installed module
'PnP.PowerShell' with version '1.12.0' under the directory 'C:\Program
Files\WindowsPowerShell\Modules\PnP.PowerShell\1.12.0'. If you still want to install or update, use -SkipPublisherCheck
parameter.

Any idea how to resolve?  I am using PowerShell v7.4.5

I installed 2.99.23-nightly.  I got a few steps further.  It received the pop-up window, entered the code provided, signed in using my Entra ID and password (and entering code in MS Authenticator) as prompted by the pop-up Window, then closed the pop-up Window as instructed.  Now it's stuck, displaying the following.
WARNING:
No permissions specified, using default permissions
WARNING:
Please login.

We opened a popup window and navigated to https://microsoft.com/devicelogin

Enter code: E5LQZXYYE (we copied this code to your clipboard)

NOTICE: close the popup after you authenticated successfully to continue the process.

I’ve finally figured out how to get past the issue I encountered with the running the cmdlet ... below are the steps I followed.   Hopefully this will help others ...
I was able to register PowerShell for APP-based access as (sort of) described here using the following steps:

I first had to remove my existing version of PnP.PowerShell under PowerShell v7.x … So, I opened a PowerShell v7.x window and then executed the command “Uninstall-Module PnP.PowerShell”
Once uninstalled, I then ran the command “Install-Module PnP.PowerShell -AllowPrerelease -SkipPublisherCheck -Force” – that installed the very latest ‘nightly’ release of PnP.PowerShell

Once that was installed, I was able to run the command

$result = Register-PnPAzureADApp -ApplicationName "PnP PowerShell Task" -Tenant mysticdev.onmicrosoft.com -OutPath c:\certs -CertificatePassword (ConvertTo-SecureString -String "password" -AsPlainText -Force) -Interactive
as described here
NOTE a couple of things:

The command I ran is slightly different than described in the original post above … when you look up the cmdlet “Register-PnPEntraIDApp”, it is actually a pseudonym for Register-PnPAzureADApp, and this latter command provided me with additional functionality that it looks like I needed
After the command executes and completes, run the command $result.Base64Encoded > c:\certs\Base64Key.txt to save the Base64Key value to a file just in case it is needed later

This opened a login pop-up window asking me to login
The cmdlet then initiated a consent workflow which (after a few secs) displayed another login window

After logging in the following was displayed, and I clicked Accept

The result was creation of the relevant app reg with corresponding ID

In addition, the relevant certificates were created and stored in the location specified with the -Outpath parameter

I can confirm that Register-PnPEntraIDApp with the -DeviceLogin parameter hangs after successfully authenticating and having closed the tab as requested.

I'm getting this error still as well. I'm on the newest version of the nightly. I followed @renewtx instructions. I removed the -Interactive flag because it said it was invalid. I got the pop-up for login, logged in with my account, but my Powershell window is still stuck on
WARNING:
No permissions specified, using default permissions


loopback messages to other websockets as well

before multiple concurrently connected websocket clients on the same api would not see messages sent by other clients
sorry i missed that in #1205

maybe messages should also be appended to the ringbuffer there so they are accessible to /api/stream and /api/messages ?


Return source and source list regardless of state

Description:
Receivers in general can passthrough the video/audio to the TV when the receiver state is off. Therefore, it is still useful to return the source/sourcelist even when the receiver is off.
I am updating just the denonavr code but all receiver code should be updated accordingly.

Hi @yraghu,
It seems you haven't yet signed a CLA. Please do so here.
Once you do that we will be able to review and accept this pull request.
Thanks!

Changing it in that location would change every MediaPlayerDevice and I
don't believe that is what should be done.
I assume for the majority of media players, if the state is off, maybe we
do not want to send attributes. But for A/V Receivers that implement the
MediaPlayerDevice, I believe this change should be done.
On Thu, Jan 9, 2020 at 1:10 AM Martin Hjelmare<EMAIL_ADDRESS>wrote:

Closed #30447
https://github.com/home-assistant/home-assistant/pull/30447.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/pull/30447?email_source=notifications&email_token=AB32PKSLUZV6E237ATX4G6LQ425VLA5CNFSM4KCRE3BKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOV3ORQ4Q#event-2933725298,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB32PKSX6BCJ43WHBBC7GNDQ425VLANCNFSM4KCRE3BA
.

We don't change how we present base entity attributes on a platform basis. Changing the behavior around this will need a change on the entity base level regardless of what behavior is wanted.


feat: support monitoring WebSocket endpoints

Summary
Solves #492
Checklist

[x] Tested and/or added tests to validate that the changes work as intended, if applicable.
[X] Updated documentation in README.md, if applicable.

Current tests:
$ make test
go test ./... -cover
?       github.com/TwiN/gatus/v5        [no test files]
?       github.com/TwiN/gatus/v5/alerting       [no test files]
ok      github.com/TwiN/gatus/v5/alerting/alert (cached)        coverage: 100.0% of statements
ok      github.com/TwiN/gatus/v5/alerting/provider      (cached)        coverage: 100.0% of statements
ok      github.com/TwiN/gatus/v5/alerting/provider/custom       (cached)        coverage: 95.1% of statements
ok      github.com/TwiN/gatus/v5/alerting/provider/discord      (cached)        coverage: 95.5% of statements
ok      github.com/TwiN/gatus/v5/alerting/provider/email        (cached)        coverage: 70.0% of statements
ok      github.com/TwiN/gatus/v5/alerting/provider/github       (cached)        coverage: 82.4% of statements
ok      github.com/TwiN/gatus/v5/alerting/provider/gitlab       (cached)        coverage: 85.7% of statements
ok      github.com/TwiN/gatus/v5/alerting/provider/googlechat   (cached)        coverage: 95.9% of statements
ok      github.com/TwiN/gatus/v5/alerting/provider/matrix       (cached)        coverage: 97.0% of statements
ok      github.com/TwiN/gatus/v5/alerting/provider/mattermost   (cached)        coverage: 95.6% of statements
ok      github.com/TwiN/gatus/v5/alerting/provider/messagebird  (cached)        coverage: 90.9% of statements
ok      github.com/TwiN/gatus/v5/alerting/provider/ntfy (cached)        coverage: 51.7% of statements
ok      github.com/TwiN/gatus/v5/alerting/provider/opsgenie     (cached)        coverage: 90.0% of statements
ok      github.com/TwiN/gatus/v5/alerting/provider/pagerduty    (cached)        coverage: 79.5% of statements
ok      github.com/TwiN/gatus/v5/alerting/provider/pushover     (cached)        coverage: 92.3% of statements
ok      github.com/TwiN/gatus/v5/alerting/provider/slack        (cached)        coverage: 95.3% of statements
ok      github.com/TwiN/gatus/v5/alerting/provider/teams        (cached)        coverage: 95.5% of statements
ok      github.com/TwiN/gatus/v5/alerting/provider/telegram     (cached)        coverage: 91.7% of statements
ok      github.com/TwiN/gatus/v5/alerting/provider/twilio       (cached)        coverage: 33.3% of statements
?       github.com/TwiN/gatus/v5/config/remote  [no test files]
?       github.com/TwiN/gatus/v5/core/ui        [no test files]
?       github.com/TwiN/gatus/v5/storage        [no test files]
?       github.com/TwiN/gatus/v5/storage/store/common   [no test files]
?       github.com/TwiN/gatus/v5/test   [no test files]
--- FAIL: TestPing (0.00s)
    client_test.go:69: expected true
    client_test.go:71: Round-trip time returned on success should've higher than 0
FAIL
        github.com/TwiN/gatus/v5/client coverage: 67.4% of statements
FAIL    github.com/TwiN/gatus/v5/client 3.967s
ok      github.com/TwiN/gatus/v5/config (cached)        coverage: 83.9% of statements
ok      github.com/TwiN/gatus/v5/config/connectivity    (cached)        coverage: 100.0% of statements
ok      github.com/TwiN/gatus/v5/config/maintenance     (cached)        coverage: 100.0% of statements
ok      github.com/TwiN/gatus/v5/config/ui      (cached)        coverage: 78.3% of statements
ok      github.com/TwiN/gatus/v5/config/web     (cached)        coverage: 81.8% of statements
ok      github.com/TwiN/gatus/v5/controller     (cached)        coverage: 78.6% of statements
ok      github.com/TwiN/gatus/v5/controller/handler     (cached)        coverage: 78.9% of statements
--- FAIL: TestIntegrationEvaluateHealthForICMP (0.00s)
    endpoint_test.go:741: Conditions '[CONNECTED] == true' should have been a success
    endpoint_test.go:744: Because the connection has been established, result.Connected should've been true
    endpoint_test.go:747: Because all conditions passed, this should have been a success
FAIL
        github.com/TwiN/gatus/v5/core   coverage: 85.9% of statements
FAIL    github.com/TwiN/gatus/v5/core   2.838s
ok      github.com/TwiN/gatus/v5/jsonpath       (cached)        coverage: 97.1% of statements
ok      github.com/TwiN/gatus/v5/metrics        (cached)        coverage: 100.0% of statements
ok      github.com/TwiN/gatus/v5/pattern        (cached)        coverage: 100.0% of statements
ok      github.com/TwiN/gatus/v5/security       (cached)        coverage: 61.2% of statements
ok      github.com/TwiN/gatus/v5/storage/store  (cached)        coverage: 93.5% of statements
ok      github.com/TwiN/gatus/v5/storage/store/common/paging    (cached)        coverage: 100.0% of statements
ok      github.com/TwiN/gatus/v5/storage/store/memory   (cached)        coverage: 88.8% of statements
ok      github.com/TwiN/gatus/v5/storage/store/sql      (cached)        coverage: 81.6% of statements
ok      github.com/TwiN/gatus/v5/util   (cached)        coverage: 100.0% of statements
ok      github.com/TwiN/gatus/v5/watchdog       (cached)        coverage: 51.3% of statements
ok      github.com/TwiN/gatus/v5/web    (cached)        coverage: [no statements]
FAIL
make: *** [Makefile:16: test] Error 1

Do you have any suggestions on how to test the new code in the core/websockets.go file? I'm not familiar with Golang, any suggestions/comments are greatly appreciated.

@heitorPB To answer your questions on the two failing tests about ping/icmp -- feel free to ignore them for now. They're flaky and

@TwiN Thank you for the feedback :) I addressed your points in the last commits.

Btw, I was told that the websocket library used here is not maintained, and was suggested Gorrilla instead, which is/was also unmaintaned. What are your thoughts on this?

Codecov Report
Patch coverage: 5.12% and project coverage change: -0.78% :warning:

Comparison is base (640e455) 81.65% compared to head (b562869) 80.88%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #511      +/-   ##
==========================================
- Coverage   81.65%   80.88%   -0.78%
==========================================
  Files          56       57       +1
  Lines        4350     4389      +39
==========================================
- Hits         3552     3550       -2
- Misses        617      655      +38
- Partials      181      184       +3

Files Changed
Coverage Δ

core/websocket.go
0.00% <0.00%> (ø)

core/endpoint.go
73.44% <40.00%> (-1.14%)
:arrow_down:

... and 1 file with indirect coverage changes

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

@heitorPB Thank you for the contribution!

Thank you for Gatus and the super valuable feedback you left here, @TwiN! I'll keep this in mind for the next PR :D


[Feature Request] i need ask a question

is a ways to know whit this tool,how to know when someome mute you? or extensions for this tool?

No, you can only see this information in-game by looking at their nameplate.

No, you can only see this information in-game by looking at their nameplate.

i know but this tool have extensions? because someome is say to me this tool have extensiosn then they can see if someome mute you

No, you can only see this information in-game by looking at their nameplate.

i know but this tool have extensions? because someome is say to me this tool have extensiosn then they can see if someome mute you

VRCX has no official extensions, extensions may exist by other people through forking this project but we do not at all endorse these as they could be used maliciously such as leading you on with fake information or attempt to steal your account login information. make sure to only use VRCX from official sources!

Many years ago it was possible with mods, not anymore.

No, you can only see this information in-game by looking at their nameplate.

i know but this tool have extensions? because someome is say to me this tool have extensiosn then they can see if someome mute you

VRCX has no official extensions, extensions may exist by other people through forking this project but we do not at all endorse these as they could be used maliciously such as leading you on with fake information or attempt to steal your account login information. make sure to only use VRCX from official sources!

many thanks for the info

No, you can only see this information in-game by looking at their nameplate.

i know but this tool have extensions? because someome is say to me this tool have extensiosn then they can see if someome mute you

VRCX has no official extensions, extensions may exist by other people through forking this project but we do not at all endorse these as they could be used maliciously such as leading you on with fake information or attempt to steal your account login information. make sure to only use VRCX from official sources!

then you say if someome have extensions can edit logs and make it fake? like falsify records?

then you say if someome have extensions can edit logs and make it fake? like falsify records?

you don't need extensions or modify VRCX to do this, our database technology is well known, its more about using unoffical versions could result in your account being compromised by whoever runs the unofficial version, but aside all of that what you are asking for is not possible as the status of being muted by someone is not shared over the API.


what about filtering the waves based on frequency (ie cut spectrum into highs, mids, lows), and have different colors for the different freq regions?

this is a little more of a wishlist thing, buuuut... it would be reeeeally sweet.... and i know webaudio has the capability (i'm sure there are plenty of examples online). i would possibly consider doing it myself, but this wouldn't take priority until the far future

Why is the spectrum not colored?I think that might be better


[Time-Traveling World Clock] Add day of the week with Time.

Extension
https://www.raycast.com/marky/world-clock
Description
Please also add day of the week with time. So that we know if it is tonight or tomorrow easily.
Who will benefit from this feature?
Every user
Anything else?
No response

@raycastbot close this issue

@raycastbot close this issue


initialize not linked to registered fields

In v5, when calling initialize, only values that matched actual form fields made it to state. You could generally not worry about what was on the object passed in, as it would natuarally line up with your form. With v6, everything you throw into initialize ends up in the values and initial state, whether or not there is a form field registered. That seems to lead to having to manage a known list of valid attributes before calling initialize separate from the work of simply building the form. That seems brittle and I wonder if there's not a better way.

I love this issue. It highlights what is awesome about running an open source project. You have clearly understood the inner workings of the library, and have made an intelligent critique of my design. If only all discourse (I'm looking at you, Politics!) were so thoughtful.
My answer is that the specific requirements of a fields array in v5 caused more problems than it solved, and yes, this is a problem caused by the alternative. However, fields that are not in the form will not affect the dirty/pristine calculation, as they cannot be changed. They will be submitted, however, but it seems like it would be a rare case when that is a problem. e.g. I only want to edit the address of the currently logged in user, so I make a form about that, and when it submits, we send the entire user record to the server...not that big a deal, I'd say.
If you have anything concrete behind "I wonder if there's not a better way", I'd be willing to hear it. I suppose it would not be such a huge problem to only submit fields that are in the form, but there might be people depending on cases like the address case above where they want the full record to be submitted.

@erikras Thanks for the thoughtful reply. I wish my thoughts were more constructive. I am struck by how much our codebase fit itself to the expectations of v5 (by encouraging certain patterns, for better or worse) and so the upgrade path has been a little painful, as might be expected. I think my best argument for submitting only what is linked to a form is that it fits the mental model better. I would argue that you expect that a submit, well, submits the form and nothing else. In the long run, that feels more intuitive when thinking about how to design the rest of the system. As to how to accomplish that, I would need to know more about the v6 internals than I do so far.

The issue is a little more complicated than it might seem, because (I think that) we cannot be sure that all the fields have registered themselves when INITIALIZE gets dispatched, so the filtering of "only fields displayed" would have to be done on submit, which could be awkward, because we also have functionality to examine the current values of the form, which then would not === the ones that would be submitted.

Not to mention that I use initialize to initialize a top-level wizard-style form that is made up of several different form components. Even though only the last component is registered at submission time I still want all of the fields to be submitted to the server.
Overall I think having all the values in the store give us the power to decide what to send later, but if we intentionally filter out fields earlier on we lose some of the power of redux-form.

I found this thread after starting #1520 and felt like they turned into the same discussion.
I personally don't believe that redux-form should be concerned in the least with what is mounted or unmounted.
For a simple use case, take a form spanned across multiple Tabs.  When I switch from tab to tab, the fields on the previous tab are unmounted and therefore unregistered.
This is causing the fields on the previous tab to be skipped in validation and to lose information about whether they are dirty and touched or not.
The only way I can solve this is to throw out the plugin I'm using now and roll my own Tab component that sets display: none instead of unmounting inactive tabs.
This is proof we've gone down a path that's opinionated, potentially breaks compatibility with other components as is now making me work against redux-form.
IMO, once you're telling me that what's in my DOM is important, you're breaking the very reason for redux and flux to exist.  Separation of concerns!  My store is the business logic.  My components are display logic and nothing more.  A < Field > component should be nothing more than a convenience, a way of interacting with my store.  It should not define it.
Once you tell me that my business logic is affected by what I place my DOM, you're breaking one-way data flow.
Furthering my Tabs example,  I could well want to display my form as multiple pages or tabs on a small screen and as one big form on a large screen.  Again, my business logic shouldn't care what I'm displaying, nor should it care if I implement this with mount/unmount vs display: none, and this is exactly why I'm using react and redux to begin with.
Finally, backwards compatibility aside, I don't see why the OP shouldn't be the one responsible for removing extraneous information from his initialize method. As Clayne mentioned, doing otherwise would remove power from the programmer.  I just don't see why we should stop at the onSubmit function.  Throw me the kitchen sink and let me deal with the implementation details.
:smile:  Sorry if that became a rant, othwerwise loving v6

^I'm having the exact same problem, I have a form spread over multiple tabs and everytime I switch between tabs I get a gazillion actions being called i.e register, update sync etc. This is just plain annoying.

They will be submitted, however, but it seems like it would be a rare case when that is a problem. e.g. I only want to edit the address of the currently logged in user, so I make a form about that, and when it submits, we send the entire user record to the server...not that big a deal, I'd say.

This is definitely an issue when using graphql (as it is very specific about which fields you can send). Our main issue for example is that apollo client likes to add extra keys to queried objects, which are the objects we give as initial values to redux-form. It would help us greatly if submission only returned the object keys of registered fields, as it is currently a manual process.

Because this issue saw almost no activity for a few months, I'm closing it.


sandbox/user tenant example

Description
adds user tenant service example in sandbox
Fixes #849
Type of change
-[ ] New feature (non-breaking change which adds functionality)
Checklist:

[ ] Performed a self-review of my own code
[ ] Code conforms with the style guide

PR title


Issue #124 and update to 1 4

Updating Projects to 1.4 and fixes to #124 (Dark Mode)

@pHill5136 - can you review - thanks


4-digit weather file - strange behavior

We generated a slightly imperfect 4-digit weather file using the AgMIP DSSAT translator and got some unexpected results. The format of the file did not have the 2-spaces between the "@" and "DATE" on the header line (i.e., @DATE    SRAD instead of @  DATE  SRAD). The model ran, but values of SRAD were interpreted incorrectly and the model results were very bad. But there was no error message.
Actually, the more I think about it, the model is behaving correctly because it is trying to right-justify data under the headers. Let's review this at a mini-sprint, but maybe we do nothing.

Hi Cheryl!
Yes, indeed. The weather subroutine has some routines that work with the header spaces in the weather file. If the file are not right justified in the header based on the data, even for Y2K will not work. This is some flexibility that we always had in the weather subroutine but only if the header is right justified.
The @ in the beginning of the file needs to be in the first column (first character place) of the file because the IGNORE, IGNORE2 subroutines will not work.
Please let me know if I can help with anything else
Thank you so much,
Fabio Oliveira


ConfigMap in version "v1" cannot be handled as a ConfigMap: json: cannot unmarshal bool into Go struct field ConfigMap.data of type string

Issue submitter TODO list

[X] I've looked up my issue in FAQ
[X] I've searched for an already existing issues here (legacy) and here
[X] I've tried installing latest charts and the issue still persists there
[X] I'm running a supported version of the application & chart which is listed here

Describe the bug (actual behavior)
Deploying helm fails creating application with the following error:
 * ConfigMap in version "v1" cannot be handled as a ConfigMap: json: cannot unmarshal bool into Go struct field ConfigMap.data of type string

Expected behavior
Should deploy
Your installation details

0.7.2
0.7.2

resource "helm_release" "default" {
  name             = "kafka-ui"
  repository       = "https://provectus.github.io/kafka-ui-charts"
  chart            = "kafka-ui"
  version          = "0.7.2"
  namespace        = "kafka-ui"
  create_namespace = true

  set {
    name  = "envs.config.DYNAMIC_CONFIG_ENABLED"
    value = true
  }

  set {
    name  = "envs.config.AWS_ACCESS_KEY_ID"
    value = "<redacted>"
  }
  set {
    name  = "envs.config.AWS_SECRET_ACCESS_KEY"
    value = "<redacted>"
  }

  set {
    name  = "envs.config.KAFKA_CLUSTERS_0_NAME"
    value = "<redacted>"
  }

  set {
    name  = "envs.config.KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS"
    value = replace("<redacted>", ",", "\\,")
  }

  set {
    name  = "envs.config.KAFKA_CLUSTERS_0_PROPERTIES_SECURITY_PROTOCOL"
    value = "SASL_SSL"
  }

  set {
    name  = "envs.config.KAFKA_CLUSTERS_0_PROPERTIES_SASL_MECHANISM"
    value = "AWS_MSK_IAM"
  }

  set {
    name  = "envs.config.KAFKA_CLUSTERS_0_PROPERTIES_SASL_CLIENT_CALLBACK_HANDLER_CLASS"
    value = "software.amazon.msk.auth.iam.IAMClientCallbackHandler"
  }

  set {
    name  = "envs.config.KAFKA_CLUSTERS_0_PROPERTIES_SASL_JAAS_CONFIG"
    value = "software.amazon.msk.auth.iam.IAMLoginModule required;"
  }

}

Steps to reproduce
terraform apply
Screenshots

Logs
No response
Additional context
No response

All ConfigMaps data must be strings. You cannot put booleans in a ConfigMap: https://kubernetes.io/docs/concepts/configuration/configmap/#configmap-object


The Search panel update request

We want to control the size of the search panel and Microsoft it would be better if you add this as a replacement to windows search or make a search like this only. That's it.

This is a duplicate, @Aaron-Junker can you search for it, thanks.

Duplicate of #6655

There is also one issue regarding the size of the PT Run UI.

There is also one issue regarding the size of the PT Run UI.

ya


Update reference-cloud-sync-faq.yml

Added cross-link to the existing detailed comparison doc of Cloud Sync vs. AAD Connect Sync classic

@TeeEarls : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#label:"aq-pr-triaged"

@billmath
Can you review this old PR and determine whether it needs to be closed or merged?
IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
@MicrosoftDocs/public-repo-pr-review-team

@TeeEarls, I have taken this change on my end.  Since we merged all the documentation, this PR has a merged conflict.  So I will just add it on my end.  It should be live later today.  Thanks!
#please-close

https://github.com/MicrosoftDocs/azure-docs-pr/pull/238394


Panic when parsing a file containing invalid UTF-8

While it might be safe to assume that data passed to this library is valid UTF-8, there are circumstances where that might not be the case. In my particular use-case I am trying to guess which file format a file has and among the valid options is a compressed archive. This causes a panic due to the following line:
https://github.com/georust/kml/blob/b53faee9c5c4a4b742ce7f693a580c9dc7ec0962/src/reader.rs#L1001
In my opinion, this should be passed out to the user of the library instead of panicking. At the very least it should be an .expect("...") to give some context. Especially in cases of file corruption, this could be hit when parsing an otherwise valid KML — crashing the hosting application 😢

Let me know if you would be open to PRs, I could create a fix in a bit 🙂

I looked through the whole reader and it appears there are two more occurrences of a similar kind:
https://github.com/georust/kml/blob/b53faee9c5c4a4b742ce7f693a580c9dc7ec0962/src/reader.rs#L1117-L1118

Thanks for the report! It looks like this should have been fixed through the update to string handling here but was missed
https://github.com/georust/kml/blob/b53faee9c5c4a4b742ce7f693a580c9dc7ec0962/src/reader.rs#L1013-L1018
I think handling it similarly with forced decoding is the most straightforward approach. PRs welcome!

@TilBlechschmidt thanks again for reporting this! Are you still interested in creating a PR? No worries if not, just wanted to check if I should put something in

Hey @pjsier, sorry for the late reply. I am still interested but not quite sure when I'll get to it (could be a couple of weeks). So if anyone else would be interested in tackling this in the meantime feel free to do so! 🙂


Copyright Update

Updated copyright headers (Names & Dates)
(Largest amount of changes by far)

Looks fine. But, are we updating copyrights for all files, even ones without changes this year? Also, is it possible to change @copyright Copyright (C) 2023 dātma, inc™ to @copyright Copyright (c) 2023 dātma, inc™ to keep to the existing pattern?

Yes, as it stands right now, we are updating copyrights for all files that have had an ODA copyright within them. They aren't updated based on the modification date. Also, the Copyright (c) capitalization should be fixed now!


Unclear uri of selected video

Does this package support video files? Like to play it or copy it? When I select video file I get this "uri": "ph://A38FEE7B-C1CB-4EC5-A887-8BCD1040FE50"

this lib allow you to select multiply images or videos and get the object that define each one , with the url and path of the file.
from this state you can use ur own logic to upload it, run it, whatever you need.

@EKOLX please open new issue if this continue on new version