Response caching for Thanos

This is an umbrella issue for things we might need to do/contribute in order to have smooth Thanos response caching.
As you probably know Cortex query-frontend now supports Prometheus API, so - it can be put on top of Thanos. Still, there are some cases we have to/can improve for Thanos usage:
Must:

[ ] Understanding underlying block structure and downsampling handling. Query frontend splits by day. This does not make sense for our downsampling which helps to run queries for large time ranges. Also split by day when querying 2w block might be not that efficient as most of the index lookup has to be 14x duplicated. However, splitting allows for easier load balancing and distributing the queries across system. This means that we might want maybe a bit smarter query split. Some idea would be:

// thanosQuerySplitIntervalFn returns split interval based on query step. This is based on the fact that
// Thanos in auto-downsampling mode will choose also use step when choosing what resolution to use.
//
// Splitting rationales:
// Cortex splits by day and it's quite a good ratio of chunks per series to fetch. For 1 day we will have approx 24 chunks/series (30s scrape). Also
// To max keep 24 chunks per series for 5m resolution it means 10 days split, for 1h resolution 120 days.
var thanosIntervalFn = func(r Request)time.Duration {
	step := time.Duration(r.Step()) * time.Millisecond
	if step > 30 * time.Minute {
		return 120 * day
	}
	if step > 5 * time.Hour {
		return 10 * day
	}
	return day
}

This might be some improvement, but still, there are some edge cases:

Fallback to raw chunks if downsampled blocks are still missing
Downsampled blocks appear only after 40h (5m) and 10d (1h), so this logic might need to consider time as well.
Split by day efficiency might differ across time, depending on how many blocks are touched.

I think there is still no clear idea of what's the best practice there. Ideally, we would split based on the underlying block structure, but there is no easy way to have that info during query planning level.
Maybe treating query splitting and splitting response a separate steps make more sense? Right now response caching relies on splitting as the cache key depends on queried start time. This is to avoid lookup logic in the caching layer.

[ ] Allow setting custom query params to Cortex frontend

[ ] Auto downsampling has to be used for the above interval based on step logic.
[ ] Partial response must NOT be cached. This can be achieved by simply setting --query.nopartial-response` however we can also add some logic for caching to be avoided if the response has some special header.
NOTE that currently partial response is not assumed if StoreAPI is down for short time for some reason (INFO not responding, Service discovery not discovering it for some time). We might need to change this to assume partial response in those cases as well to avoid the wrong cached results. The alternative is to invalidate the cache in those cases. Which below point enables.

[ ] Adjust for StoreAPI changes: Expose on Querier some info_hash HTTP API that will be used by cacher to get hash and use it as cache key? How to ensure we are up to date with store API changes? Maybe short TTL is fine?

Could:

[ ] Discuss cortex to move query-frontend caching logic out of Cortex project: https://github.com/cortexproject/cortex/issues/1672
[ ] Use it inside Querier directly: https://github.com/thanos-io/thanos/issues/1006 as a library.

Anything I missed? Feedback, ideas, and help wanted (:

Updated this with recent findings and ideas. Design doc and MVP in progress (:

We should document Cortex's query-frontend as the recommended solution + how to enable the most usual use-cases with --store-strict.

Yes. But there might be even better solution. Issue coming.
On Mon, 13 Apr 2020, 22:47 Giedrius Statkevičius<EMAIL_ADDRESS>wrote:

We should document Cortex's query-frontend as the recommended solution +
how to enable the most usual use-cases with --store-strict.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/thanos-io/thanos/issues/1651#issuecomment-613113957,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABVA3O7ZJJDD5QR7XNPHG4TRMOB65ANCNFSM4JA27Y7Q
.

Proposal that should solve your concern @GiedriusS (and mine as well): https://github.com/thanos-io/thanos/pull/2434

Will be done as part of https://thanos.io/proposals/202004_embedd_cortex_frontend.md/

in progress!
On Wed, 17 Jun 2020 at 19:15, stale[bot]<EMAIL_ADDRESS>wrote:

Hello 👋 Looks like there was no activity on this issue for last 30 days.
Do you mind updating us on the status? Is this still reproducible or
needed? If yes, just comment on this PR or push a commit. Thanks! 🤗
If there will be no activity for next week, this issue will be closed (we
can always reopen an issue if we need!). Alternatively, use remind command
https://probot.github.io/apps/reminders/ if you wish to be reminded at
some point in future.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/thanos-io/thanos/issues/1651#issuecomment-645538197,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABVA3O5OGHQX4XU5BDWCWHTRXEB2VANCNFSM4JA27Y7Q
.

https://github.com/thanos-io/thanos/pull/3018 is merged so I think it is time to get back to this issue.
Just opened a pr on the Cortex side to support dynamic split interval https://github.com/cortexproject/cortex/pull/3066. It would be great if anyone can help review it!
@bwplotka Would you mind updating the issue checklist? I believe Partial response must NOT be cached. This can be achieved by simply setting --query.nopartial-response however we can also add some logic for caching to be avoided if the response has some special header.` is already done.

Updates on this issue:
Auto downsampling has to be used for the above interval based on step logic. and Allow setting custom query params to Cortex frontend should be done.
For the dynamic split interval for downsampled block, sorry I don't really understand how to calculate 10d, 120d, 30m and 5h here, can you please explain it? Since we already support getting max_source_resolution directly, we can use it here directly I think.
var thanosIntervalFn = func(r Request)time.Duration {
	step := time.Duration(r.Step()) * time.Millisecond
	if step > 30 * time.Minute {
		return 120 * day
	}
	if step > 5 * time.Hour {
		return 10 * day
	}
	return day
}

Fallback to raw chunks if downsampled blocks are still missing

How does query frontend know that downsampled blocks are missing? I think we don't need to deal with this on query frontend.

Downsampled blocks appear only after 40h (5m) and 10d (1h), so this logic might need to consider time as well.

This is something we talked about offline, so how does query frontend know that there are downsampled blocks in bucket?


[feature]Redesign Login Page with Enhanced Background Image and Styling

The current login page on our project needs a redesign to improve its visual appeal and user experience. This issue aims to enhance the login page by incorporating a more captivating background image and refining the overall styling.
Current Login Page Observations:

Dull Background: The current background on the login page lacks visual interest and may not create a positive first impression for users.

Inconsistent Styling: The styling elements on the login page may appear inconsistent, making it challenging for users to engage seamlessly.

Limited User Engagement: A well-designed login page can create a welcoming atmosphere, encouraging users to interact with our platform.

Desired Redesign:

Background Image: We propose to select a high-quality background image that aligns with the project's theme and enhances the page's aesthetics. The image should be relevant and appealing to engage users positively.

Color Scheme: We will establish a consistent color scheme for the login page that complements the background image and creates a visually cohesive design.

Typography: The typography used on the page will be chosen carefully to ensure readability and aesthetic appeal.

Responsive Design: The login page will be made responsive to ensure optimal viewing on various devices, including desktops, tablets, and mobile phones.

User-Friendly Elements: The login form and other interactive elements will be designed to be intuitive and user-friendly, streamlining the login process.

Benefits of the Redesign:

Enhanced User Experience: The revamped login page will create a positive first impression and encourage users to interact confidently with our platform.

Improved Branding: A visually appealing login page will align with our project's branding, contributing to a more consistent and professional image.

Increased User Engagement: The revamped design, combined with the captivating background image, can lead to increased user engagement and retention.

Next Steps:

Design Exploration: Our design team will explore different background images, color schemes, and typography options to identify the most suitable design.

Code Implementation: Once the design is finalized, our development team will implement the changes to the login page using modern HTML, CSS, and JavaScript practices.

Testing and Feedback: After implementation, we will conduct thorough testing to ensure the login page is responsive, bug-free, and aligns with our project's objectives. User feedback will also be valuable in refining the design.

Deployment: The redesigned login page will be deployed to the production environment, providing users with an improved login experience.

We believe that redesigning the login page will significantly contribute to the overall user experience on our platform. Your suggestions and collaboration on this issue are highly appreciated as we work towards creating a more visually appealing and user-friendly login page

@Gaurav-Verma07 ,please assign me this issue

This is just styling example i will use sampark images and logo to customise this login form please assign me this issue


refactor(graphql): Migrate Visual Config into the Configuration Provider

follow consistent config semantics as auth, ingest, telemetry

Checklist

[ ] The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
[ ] Links to related issues (if applicable)
[ ] Tests for the changes have been added/updated (if applicable)
[ ] Docs related to the changes have been added/updated (if applicable). If a new feature has been added a Usage Guide has been added for the same.
[ ] For any breaking change/potential downtime/deprecation/big changes an entry has been made in Updating DataHub

Waiting for checks then will merge.


babel: target current node in SSR builds

IMO people usually use same node version in their build env and (production) runtime env, targeting node to current version will let user benefit from using latest, non-LTS node versions

@whtsky OK, but some important concerns:

How can we ensure that people are using same node version for Dev, CI and production envs ?
What benefits with using current instead of 8.0.0 will we actually have?

Another note, Nuxt dist itself is bundled against 8.0.0 using rollup as we require 8.0.0 as the minimum supported version in package.json. So this may make things more unpredictable.
Also presets is configurable using a function with nuxt.config.js:
build: {
 babel: {
   presets({ isServer }) {
      // Return a customized preset
   }
 }
}

we can't. But node is not fully backward compatible, so running different versions for Dev, Ci & Prod would be an issue anyway. And I think it's really unlikely to have problems since babel should handle it perfectly.
there's no actually benefits right now, but I think it's cool if there's a new Node version and I can use the new features natively w/o transpiles in my nuxt app by simply upgrading node version

But node is not fully backward compatible

I think it's more likely to be LTS backward compatible rather than forward compatible :))
Anyway, i agree with you. Less transpilation and preferring native version is always so nice. Especially currently the browser version is not configurable enough at least in a gentle manner. What's your idea if you change this PR to make target configurable like this:
nuxt.config.js
{
build: {
  target: {
    client: { ie: 9, uglify: true }, // Can be customized
    server: { node: '8.0.0' } // Can be customized
  }
 }
}

looks great. It's late in China so I'll do it tomorrow :)

Cool. Thanks for your help :)

just use this in your nuxt.config.js and it should do what you like to have ;).
 babel: {
        presets: function(isServer) {
            return [
                [
                'vue-app', {
                    useBuiltIns: true,
                    targets: isServer ? { node: 'current' } : {ie: 9, uglify: true}
                }]
            ];
        }
    },

regards
Simon


🐛 QR code image loading over HTTP

Cc: @bradystroud
Hi SSW.Rules Team,
Describe the Bug
In Firefox, Rules pages are showing a Connection is not secure error, due to a QR code loading from an http address: http://www.ssw.com.au/ssw/Images/QRcode.jpg
NOTE: The issue is not seen in Chrome/Edge, as they automatically "upgrade" the request to HTTPS.
To Reproduce
Steps to reproduce the behavior:

Open Firefox
Go to https://www.ssw.com.au/rules/stick-to-the-agenda-and-complete-the-meetings-goal (or any Rule page)
See error

Figure: Firefox | Rules page | mixed content
Expected Behavior
All content should be loaded securely.
Tasks

[ ] Investigate
[ ] Fix

Thanks!

Hey @chrisschultzssw

[x]  Investigate
[x]  Fix

✅ Both done
https://www.ssw.com.au/rules/

Figure: Connection secure - Firefox is happy


Fix copy invite room message

Details

Fix copy invite room message
Fixed Issues

$ https://github.com/Expensify/App/issues/30272
PROPOSAL: https://github.com/Expensify/App/issues/30272#issuecomment-1777621410
Tests

Create a room
Click on the header of the room > Invite
Invite some users
After the invite message appears, hover over this message and click on copy to clipboard
Paste it to composer, verify that the message that is copied is the same as the invite message displayed
Go to admin room of the workspace
Copy policy log of invite action above
Paste it to composer, and verify that the message that is copied is the same as the invite message displayed

[x] Verify that no errors appear in the JS console

Offline tests

None
QA Steps

Create a room
Click on the header of the room > Invite
Invite some users
After the invite message appears, hover over this message and click on copy to clipboard
Paste it to composer, verify that the message that is copied is the same as the invite message displayed
Go to admin room of the workspace
Copy policy log of invite action above
Paste it to composer, and verify that the message that is copied is the same as the invite message displayed

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes

[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)

[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native
https://github.com/Expensify/App/assets/129500732/162b49ee-bf34-4df8-a0e7-58e8e773d50e
https://github.com/Expensify/App/assets/129500732/112a7867-6d3e-477b-b8f8-52987e86bd7d

Android: mWeb Chrome
https://github.com/Expensify/App/assets/129500732/b5f26c88-6b3e-4ae0-b2f7-1ed98cb52ee3

iOS: Native
https://github.com/Expensify/App/assets/129500732/f123a672-ec97-4375-baa8-544fca58100e

iOS: mWeb Safari
https://github.com/Expensify/App/assets/129500732/8bb9ae93-477d-4009-97f8-0ec446c296b3

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/129500732/27763874-9904-4a7e-9ab2-cb373d061e65

MacOS: Desktop
https://github.com/Expensify/App/assets/129500732/e63f5a64-7a6d-477a-ab12-109ffffdcad7

Bad news: I think we'll need to expand the scope of the PR to handle another variant of the invited @foo, @bar, @baz message, which is nearly the same as ours, but not quite.
In the #admins channel, we have a message variant like this:

@dukenv0307 Great! We'll need to expand the testing steps. When you do this, please re-upload at least the Web platform video.

I'm having trouble observing the invite logs in the #admins channel...
In one case, I got information about one user being invited to a room when I invited three users at once:

In another case, I got no update about adding inviting to a room.
Do you always get reliable logs in #admins about the invited users, no matter how many you add at once?

@cubuspl42 Can you share a video for this case?

https://github.com/Expensify/App/assets/2590174/1a62275b-5348-49be-9159-05206d48c6de

invited<EMAIL_ADDRESS><EMAIL_ADDRESS>and<EMAIL_ADDRESS>
...but in #admins only:

invited<EMAIL_ADDRESS>to #social12

I'm not saying this is something your PR introduced, but it complicates the testing 🫤

@dukenv0307 I'll re-test

Reviewer Checklist

[x] I have verified the author checklist is complete (all boxes are checked off).
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[x] I verified proper code patterns were followed (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I verified that this PR follows the guidelines as stated in the Review Guidelines
[x] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web
https://github.com/Expensify/App/assets/2590174/19b7fa7b-3052-4147-8d45-9a13ffebeaa4

Mobile Web - Chrome
https://github.com/Expensify/App/assets/2590174/631f033c-5037-4193-b968-b2973e930a7b

Mobile Web - Safari
https://github.com/Expensify/App/assets/2590174/e98ed263-a41a-444a-b2bc-e5cdfb1be686

Desktop

iOS
https://github.com/Expensify/App/assets/2590174/fb1b83b1-0bde-4c54-9d67-adda0fef91f4

Android
https://github.com/Expensify/App/assets/2590174/74d4bda6-6421-4bec-85c9-2d45acf0dd7c

@dukenv0307 Thank you for reminding me. I submitted the checklist without approving.

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to production by https://github.com/luacmartins in version: 1.4.1-13 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Add Profile: no option for profile addition

A pull request should be created from this issue if not kindly ping @dinxsh ⚠

you can assign this task to me...


Update SbgEkfNav & SbgEkfGpsPos position from Vector3 to float64 LLA

to correctly address this issue, we should update the following messages def:

SbgEkfNav.msg
SbgEkfGpsPos.msg

We should replace position geometry_msgs/Vector3 to three members that are latitude/longitude/altitude

Integrated in PR #62


Stack creation fails on S3 403 error

Running stack deployment using the console link in the Readme. Get the following permissions error trying to create the stack, resulting in rollback:
Your access has been denied by S3, please make sure your request credentials have permission to GetObject for rodeolabz-us-east-2/live-streaming-on-aws/livecaptionsv1cbs/TranscribeStreamingJavaLambda.jar. S3 Error Code: AccessDenied. S3 Error Message: Access Denied (Service: AWSLambdaInternal; Status Code: 403; Error Code: AccessDeniedException; Request ID: 791e0593-1ff5-11e9-92f3-b55ab87d2b9b)

Thanks for pointing this out. I had to add a --acl public-read to make the files reachable.
But this CloudFormation will not work in Ohio (us-east-2), since AWS MediaPackage is not been made available in that region. This solution uses AWS MediaLive and AWS MediaPackage. This link shows the regions that those two services are supported in.
https://docs.aws.amazon.com/general/latest/gr/rande.html


Support automatic table schema evolution

Description
In my organization we use clickhouse as analitical database that gets it's data from multiple sources via Kafka. Domain models change from time to time as business changes and we found a need to reflect those changes in the clickhouse manually a little inconvenient.
Would be awesome if this connector could propagate changes in schemas to the clickhouse tables automatically.
Additional context
Compatibility modes in kafka:
https://docs.confluent.io/cloud/current/sr/fundamentals/schema-evolution.html#compatibility-types
JDBC connector that has this functionality:
https://github.com/confluentinc/kafka-connect-jdbc

Not sure how it's done in jdbc connector. Wouldn't it be possible to use separate KeeperMap table to synchronize tasks?


Auto-detected npm tasks run in the wrong directory

VSCode Version: 1.17.2
OS Version: Win10

Steps to Reproduce:

Open a folder with
package.json:

{
  "name": "foo",
  "scripts": {
    "test": "echo abc"
  }
}

Do Tasks -> Run Task... -> select npm: test
It fails as it is run in the project folder's parent directory:
npm ERR! enoent ENOENT: no such file or directory, open  'C:\Users\user1\Workspace\package.json'

Reproduces without extensions: Yes/No (haven't tried yet)

@vp2177 I cannot reproduce this given the steps above, pls see the screenshot below. Can you attach the output you are seeing in the terminal.

Actually I was wrong, npm run test is not run in the parent folder, but always in C:\Users\<my-user>\Desktop\Workspace. It appears PowerShell is used as the terminal (by default?), and in my PowerShell profile, there is a cd command into this directory.

If I change the terminal that is used to cmd, running tasks works. I guess regardless of terminal, changing to the folder with the package.json before running the task would solve this

in my PowerShell profile, there is a  cd  command into this directory.

This explains it, thanks. The extension is doing a cd folder in a multi-folder setup, in a single folder setup the assumption is that the shell is spawned in the workspace folder. Since it is no a common setup to do a cd in the PS profile. I can either add a setting or always do a cd. What do you think?

@egamma I am not a fan of adding a cd into the command line since this makes all your code shell specific. The way to go is to let the system know how to start the shell when the task is run. In the case described this can be done by either specifying the shell per task or globally in the tasks.json. There is a feature request to even allow specifying it in a shell.
However there is currently a problem with this and contributed tasks. See https://github.com/Microsoft/vscode/issues/36154
To fix this we should address 36154 and then have this in the tasks.json
    "windows": {
        "options": {
            "shell": {
                "executable": "...\\powershell.exe"
                "args": [
                    "-NoProfile", "-Command"
                ]
            }
        }
    }

Sorry perhaps it's already this way, but if not, I think which shell to use for the integrated terminal (user's personal preference) should be independent of which shell is used when spawning tasks (configurable but by default should be cmd or PowerShell with -NoProfile)

See also #36342

The proposal from @dbaeumer in https://github.com/Microsoft/vscode/issues/37721#issuecomment-342759115 resonates with me and I suggest to close this issue in favor of  #36154

Yes on a second thought this is a duplicate of #36154


[Bug] Status field populated with null in incremental running

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the issue
Hi
Regarding the field : status in table : JIRA__DAILY_ISSUE_FIELD_HISTORY.
When I run full running the field populate fantastic, but when I run incremental running the field populate with null values.
I investigate the code and see that in the high version of package(version: 0.9.0) the value in the table is status_name, in the low version(version: 0.6.0) the value is status_id, and when the value is status_id the problem not happen, because in high version the join is between status_id and status_name:
In this table status_id:
select *
from BIPRODDB.dwh_actimize_jira.int_jira__field_history_scd
where valid_starting_on >= (select max(date_day) from BIPRODDB.dwh_actimize_jira.jira__daily_issue_field_history )
In this table status_naem:
select *
from BIPRODDB.dwh_actimize_jira.jira__daily_issue_field_history
where date_day = (select max(date_day) from BIPRODDB.dwh_actimize_jira.jira__daily_issue_field_history )
And if the value arrived from the second table(most_recent_data) and join to status table with status_id, it will be null...
Relevant error log or model output
No response
Expected behavior
I expect to get the last value of status and not null, need to change or remove the join to status table, in cases that the value arrived from target table and not from the increment table.
dbt Project configurations
name: 'actimize_project'
version: '1.0.0'
config-version: 2
vars:
  # jira_issue_history_buffer: 12
  issue_field_history_columns: ['acceptance owner','acceptance criteria','action completed date','actual delivery date','actual pi','aggregated done story points','aggregated remaining story points',
                                'aggregated story points','aha url','analysis status','append release notes','artifact id','artifact version','artifactory link','assignment type','automated',
                                'backlog rank','begin date','bug origin','candidate for automation','capitalize','clone','closed','code freeze date','commitment level','commitment type','cs task id',
                                'cs task owner','customer','customer facing guides - docenter','customer facing guides - sandbox','customer impact','customer priority','documentation completed',
                                'documentation link','documentation required','draft document url','end date','environment name','epic color','epic description','epic link','epic name','epic planned pi',
                                'epic status','epic story points','epic type','escape analysis category','eta given date','expected next update','external issue id','field readiness notes','fix notes',
                                'flag - comment added','flag - status changed','found by automation','found on build','fr status','functionality','functionality required version','gdpr files location',
                                'git link','guide names','guide page\section','guide version','high level estimate','impact','installation steps','instance sp','instance version','internal facing guides - docenter',
                                'internal facing guides - sandbox','investigation steps','issue color','justification','last status change','last updated by wiser','limitation reason','limited release',
                                'link to case/sr','link to cs task','link to task','milestone','old issue key','origin','original estimate','originated in version','os type','overall cst priority',
                                'packaging status','planned date','planned pi','planned release','possible root cause','priority customer','product','project type','quality reason','quality sub-reason',
                                'rank','regression','release highlights','release notes','release on scope','release on time','release type','reopen counter','requested date','requested pi','requested release',
                                'required actions','requirement category','resolution name','resolution type','resolved date','risk score','rn description','rn fix','rn summary','rollback instructions',
                                'root cause analysis','root cause for no automation','rtc id','run on build','sdc link','severity','shared attachment folder','short description','shortcut opportunity',
                                'shortcut opportunity description','solution required version','start date','steps to reproduce','story description','story points','support quality of escalation','svn commits',
                                't-shirt size','task classification','task id','team name','technical availability date','technical description \ limitation','tenant id','test coverage type','url to rtc',
                                'url to tracker','version','virus scan status','wa bug created','wiser attachments','wiser case / sr owner','wiser case/sr#','wiser parent creation date','wiser sysid','wiser task cancellation reason']

  jira_database: fivetran_actimize
  jira_schema: jira_cloud_prod

models:
  +copy_grants: true
  jira:
      +schema: dwh_actimize_jira
  jira_source:
      +schema: dwh_actimize_jira

Package versions
packages:

package: fivetran/jira
version: 0.9.0

What database are you using dbt with?
snowflake
dbt Version
dbt Version : 1.3
Additional Context
No response
Are you willing to open a PR to help address this issue?

[ ] Yes.
[ ] Yes, but I will need assistance and will schedule time during our office hours for guidance
[X] No.

Hi @RivkiHofman thanks so much for pointing us in the right direction in regards to what may be going wrong with the incremental strategy. You were completely correct that the status join is what was returning the inaccurate status data on incremental runs.
I was able to open the above PR that should resolve this issue in our next release of the package. If you have availability, you can test these changes using the below packages.yml config in place of the official Jira version.
packages:
  - git: https://github.com/fivetran/dbt_jira.git
    revision: bugfix/status-id-matching
    warn-unpinned: false

Please be aware though that this is built off our latest version of the package (v0.12.2) as opposed to the version you highlighted in this ticket (v0.9.0). Let me know if you are able to try the work in progress branch. Thanks again!

Thanks again for helping us through identifying this issue and zeroing in on what the issue was. The latest release (v0.13.0) takes the branch you tested above into consideration. Therefore, the issue should be resolved upon upgrading to the latest version.
I will close out this issue, but please feel free to reopen if the issue persists on your end.

Thank you very much for your quick handling and kind support.


docs: latest Cloudflare Worker changes

Hi,
I tried setting up a Nuxt 3 + Nitro SSR over cloudflare workers and realized cloudflare workers .toml configuration have changed since this documentation was prepared.
e.g. https://github.com/gouthamrangarajan/cloudflare-workers/tree/main/nuxt-nitro-101

I had the same issue and it would be resolved by https://github.com/unjs/nitro/pull/444

Thanks for the PR @gouthamrangarajan ❤ Changes are merged it via #444


Structs and constants are not generated

In the README.md it is mentioned that the structs and constants should be generated when the name is written in the NativeMethods.txt
I added the following structs, but they are not generated:
CWPRETSTRUCT
CWPSTRUCT
I checked in the winmd file, it is there.
Constants are also not generated, see: https://github.com/microsoft/win32metadata/issues/150
The can be found in the winmd, too.
For example:
namespace Windows.Win32.WindowsProgramming
{
  public enum PROCESS_CREATION_FLAGS : uint

I can't repro this problem. When I specify either of those two structs I get them:

I can't repro this problem. When I specify either of those two structs I get them:

I'm closing for now for ease of bug tracking, but if you still have a problem with these structs please comment here and we can re-open.

I'm closing for now for ease of bug tracking, but if you still have a problem with these structs please comment here and we can re-open.

Ahh, so they are not in the PInvoke class.
Then maybe you should fix the documenations, since you wrote:

the P/Invoke API can be found on the Microsoft.Windows.Sdk.PInvoke class, like this:

:)

Ahh, so they are not in the PInvoke class.
Then maybe you should fix the documenations, since you wrote:

the P/Invoke API can be found on the Microsoft.Windows.Sdk.PInvoke class, like this:

:)

Sounds good. I have clarified in the readme. Thank you for the feedback.

Sounds good. I have clarified in the readme. Thank you for the feedback.


Based on feedback, changed terms used for 'third-party application'

Switched out third-party with applications to be more generic and easy to understand. Within the doc we describe that this option is only for third-party apps.

@jaszperez : Thanks for your contribution to the Azure documentation! The author, @billmath, has been notified to review your proposed change.

@Billmath because there's a merge conflict, please review these changes and if necessary make updates in the private repo. When done, close this PR giving a "please-close" with a hashtag in front of it.

I am going to fix this in a private pr and will close this once it is updated.

#please-close


[FEATURE] Inventory Display

Is your feature request related to a problem? Please describe.
N/A
Describe the solution you'd like
Display player inventory in the SRT.
Additional context
N/A

I have all of the coding required to implement this feature but I have been unable to extract the icons from the game files. Any assistance in this portion is appreciated.


Timesheet - 12/04/2021 - Tristan Spearing

Task 1
Had marketing meeting with Bojan.
Proof of Work

https://meet.google.com/kcj-rzmn-bij?authuser=0

Time Spent
0.5 hours

Task 2
Wrote copy for website
Proof of Work

https://github.com/thenewboston-developers/Marketing/issues/148

Time Spent
0.5 hours

Total Time Spent
1 hour
Account Number
6d4e7ec412472b5cfabb234555bc37f9a5a1a75a4926f9fee2a54d3e070f4b3f

Approved

Approved


Fix broken UEFI spec link in uefi-raw README.md

Removed the stray period character at the end of the link which prevented it from working

Thanks!


Go to note page after updating a note

Currently it goes to all notes page, I think it's easier to view the updates if it goes to note page.

Thanks for the feedback, I agree that this would make more sense.


Make push-client recipe open the demo page when the user clicks on a notification

Fixes regression from the cookbook page restructuring.

Should we add more logic here to check if the user was at index.html (they went directly to the demo) or ../push-clients_demo.html?  Ideally we could make the demo work in both scenarios.

Instead of making the URL depend on a stored information (that looks too specific to the cookbook website), we could make it depend on some information passed by the server.
I think it would be better because I can see a real use case behind it (e.g. a newspaper website that sends a push notification with the URL of the news).
It would still introduce some complexity in the recipe.

I am for the best guess for now.


Onboard Camel K Runtime

This is a JVM only extension

The intention is to collect early feedback.
https://github.com/apache/camel-quarkus/issues/4283
There are some parts that requires more investigation, like the use an existing camel-quarkus Runtime interface, instead of the one in the k-core/api package
Also, there are some tests disabled due to failures in the CamelContextCustomizer tests, which I am investigating.
There is the ApplicationConfigSourceProvider which I will see if it is really necessary to depend on microprofile config.

I am looking at the failed validations.

The concept of adding the camel-k-runtime as a camel quarkus module is good. Right now, the runtime release cycle is completely coupled to Camel Quarkus, so, it will simplify the release.
I can see it misses a few components such as camel-k-cron or camel-k-resume-kafka (not sure if this latest one is fully functional though, cc @orpiske). It also misses the support plugins (such as the catalog generator) or the platform bom which are used directly by Camel K to perform certain actions.

I haven't had a chance to try with camel k 2.x yet. AFAIK, we did not have any change on core that could directly affect this, so it should work (as in general - not sure about Camel K side of changes).

@squakez it is intentional to bring in only the camel-k-core and camel-k-runtime modules of the camel-k-runtime project to collect early feedback, about the project structure, naming, api usage, etc.
In the meantime I am working to bring the remaining modules.

For naming, I'm not sure I like prefixing stuff with k. I'd prefer we use camel-k, then there's no ambiguity. Do we want to name artifacts like camel-quarkus-k-core-api or just simplify to camel-k-core-api? What do others think?
Then there's the question of how we strucure things. We could either continue with what's proposed here with something like:
|- extensions-jvm
|----- camel-k
|--------- core
|--------- runtime
|--------- foo
|--------- bar

Or have dedicated top level modules for the camel-k specific stuff. E.g:
| - extensions-jvm-camel-k
|----- core
|----- runtime

For any native supported bits:
| - extensions-camel-k
|----- extension-a
|----- extension-b

And a similar split for the integration tests integration-tests-jvm-camel-k & integration-tests-camel-k.
I am generally terrible at naming / deciding these things, so it'd be good for others to comment.

For naming, I'm not sure I like prefixing stuff with k. I'd prefer we use camel-k, then there's no ambiguity. Do we want to name artifacts like camel-quarkus-k-core-api or just simplify to camel-k-core-api? What do others think?

I have a preference for camel-quarkus-k-core-api, unless there's a technical reason from Camel-k project.

Then there's the question of how we strucure things. We could either continue with what's proposed here with something like:
|- extensions-jvm
|----- camel-k
|--------- core
|--------- runtime
|--------- foo
|--------- bar

Or have dedicated top level modules for the camel-k specific stuff. E.g:
| - extensions-jvm-camel-k
|----- core
|----- runtime

This could be a first way of dealing with this.

For any native supported bits:
| - extensions-camel-k
|----- extension-a
|----- extension-b

And a similar split for the integration tests integration-tests-jvm-camel-k & integration-tests-camel-k.
I am generally terrible at naming / deciding these things, so it'd be good for others to comment.

There is the ApplicationConfigSourceProvider which I will see if it is really necessary to depend on microprofile config.

This is likely a good candidate for a first integration with Camel and/or Camel Quarkus as the goal for the ApplicationConfigSourceProvider aws to load properties in a particular order so that we can control the priority of the properties and we can also scan all the mounted secrets/configmaps.
Camel has already some priority concepts backed in the PropertiesComponent:

default properties
override properties
all the others

So we can probably model what ApplicationConfigSourceProvider does with plain Camel.
In addition to that we can add the ability to scan directories Camel Quarkus in a form of a ConfigSourceProvider

Rebased main
Bring in the catalog from camel-k-runtime tooling. The maven plugin generates a specific camel-catalog.yaml to be consumed by camel k. it is the supported set of camel components.

I will rebase and push more changes later today.

@ppalaga can you have a look at this preliminary work ?

 looks scarry, but I will have a look later today

We had a chat with @claudio4j and we agreed to work towards the following (@jamesnetherton and others please speak up if you do not like something):

The BOM currently in extensions-jvm/k/bom/pom.xml will be eliminated by moving the entries to poms/bom/pom.xml. I believe it is better both for CQ maintainers and for Camel K maintainers to have just a single BOM. The newly added entries won't be many and they will hopefully not confuse Camel Quarkus users too much.
Some modules can perhaps be merged into others, e.g. there is a chance to have just a single camel-k specific extension.
We need to figure out whether the new extension(s) needs to work in native mode (any opinion on that @lburgazzoli ?) and possibly move it from extensions-jvm to extensions. Same for the tests. Some tests will possibly have to be split into native/jvm only parts, because some DSL are only supported in JVM.
The intermediate /k/ directory should be eliminated.

Besides that, I am fine with the current camel-quarkus-k name prefix, as well as I'd be fine with camel-quarkus-camel-k or camel-quarkus-camelk.

Thanks @ppalaga I am working to materialize these changes in this PR.

Rebased and removed the camel-k bom and camel-catalog modules.

The snakeyaml-engine exclusion was removed, it was added when the first I added the tests to camel-quarkus, but over the course of updates, the exclusion is not necessary anymore.

I am still looking whether we could merge the ITs into fewer Maven modules to save some time on the CI.

Now I see that camel-k-loader does not have any assertions for native mode (there is no *IT class). Also based on what the tests are doing, I'd vote for transforming it into a lightweight deployment test -  a PR will follow.
camel-k-runtime-xml and camel-k-runtime-yaml could perhaps be merged together. Although we normally strive to test extensions with minimal set of ancillary dependencies (which would be a reason to keep the two test modules separate), but in this specific case, we can say that (1) XML and YAML DSLs are tested in isolation elsewhere and (2) the Camel K extension is rather unlikely to be "fixed" by any of the two. Let me try to merge them together.

In camel-k-runtime repository, these tests are IT enabled.
https://github.com/apache/camel-k-runtime/tree/main/itests/camel-k-itests-loader-xml/src/test/java/org/apache/camel/k/loader/xml/quarkus
It was probably some oversight of me not bringing them, which I can do now.
All of these tests are contained in their own project in camel-k-runtime, so when I brought them to camel-quarkus, I wanted to have them in the same project to save IT test time.

@claudio4j in https://github.com/apache/camel-quarkus/pull/5219 I have rebased on top of recent main and I have put a few enhancements on top of the current PR. Please review there and possibly amend to your PR.

Let's close this PR and work on #5219


Implement support for OBS multiplatform

Hi, any plans to support multiplatform soon? Or are you dependant on NodeCG updating their infrastructure?

Did some of my own research and I think it's just a matter of creating a scene in OBS MP and saving it in the obs dir. But I'm not sure if you dynamically generate the scene? I did notice that the elements appear to change size as you update them.
On a second note, do you know why sometimes scrollbars appear on the sides of elements being rendered?

There's no reason why it wouldn't work in OBS-MP. It just lacks the ability to import scenes so you'll have to add the sources manually. It would probably help if you had regular OBS also open and looked at the widths and heights of the sources in there.
As for the scrollbars, they should disappear if you enter the following in the source's CSS section:
body {
    overflow: hidden;
}

Sweet, thank you, issue can be closed. It might be a good idea to add something to the readme about needing to create your own scene if you want to work with MP. Also the stuff about overflow (I noticed the same thing happening in my install of regular OBS).

In regular OBS the scrollbars go away once you've updated from the dashboard. Odd bug, but I think it's something to do with the browser plugin.

Yeah I had a suspicion it might be because of that. Unfortunately the plugin ecosystem around MP is pretty bad. I think I should add that to my PR re: the readme actually. (No OBS remote)


CORE deposit error "Object not found in low-level storage: hc:45352" (user Melissa Ramos)

Date first reported: 4/15/2022
Date requested for completion:
Site: Humanities Commons
Area: CORE
Description
On Melissa Ramos's deposit titled "'Ni de aqui, ni de alla': Investigating the impact of documentation on Chicanx youth subcultures," the file does not appear when you click View in Browser or Download. Instead you get the message: "Object not found in low-level storage: hc:45352." She has resent it and I've tried uploading it myself and the same message appears.
Further details
Deposit: https://hcommons.org/deposits/item/hc:45351/

The Fedora record for this deposit seems to be missing or corrupted: https://hcommons.org/deposits/objects/?pid=true&label=true&state=true&ownerId=true&cDate=true&mDate=true&dcmDate=true&title=true&creator=true&subject=true&description=true&publisher=true&contributor=true&date=true&type=true&format=true&identifier=true&source=true&language=true&relation=true&coverage=true&rights=true&terms=&query=pid%3Dhc%3A45352&maxResults=20
I think the user will have to try to redeposit.

@mikethicke this deposit can now be deleted as we've replaced it with a new one.

This bad deposit has been removed. Looks like a timeout error happened with the Fedora backend.
[2022-04-10 10:33:56] humcore_error.ERROR: HumCORE Deposit Error - r_ingest : http_request_failed-cURL error 28: Connection timed out after 5001 milliseconds [] []


Import 70653ac1e8: Updated and fixed JSDoc (by Maki)

This is an automated proposal to look at a commit made by Maki and import it into Overte

Commit:
70653ac1e8ed2f82baaa2485f8af3bed17c4ba7e

Author:
Maki

Date:
Mon, 13 Jan 2020 20:20

Updated and fixed JSDoc

Stats:

Filename
Stats
Lines
Added
Removed
Lines in blame

interface/CMakeLists.txt

1
1
0
1

tools/jsdoc/.gitignore

9
3
6
3

tools/jsdoc/.prettierrc

11
11
0
11

tools/jsdoc/CMakeLists.txt

10
3
7
⚠ 0

tools/jsdoc/README.md

35
0
35
⚠ File gone

tools/jsdoc/api-mainpage.md

9
0
9
⚠ File gone

tools/jsdoc/config.json

40
24
16
⚠ 0

tools/jsdoc/gravPrep.js

671
0
671
⚠ File gone

tools/jsdoc/hifi-jsdoc-template/LICENSE.md

61
0
61
⚠ File gone

tools/jsdoc/hifi-jsdoc-template/README.md

42
0
42
⚠ File gone

tools/jsdoc/hifi-jsdoc-template/package.json

59
0
59
⚠ File gone

tools/jsdoc/hifi-jsdoc-template/publish.js

772
0
772
⚠ File gone

tools/jsdoc/hifi-jsdoc-template/static/fonts/Graphik-Regular.otf

0
0
0
⚠ File gone

tools/jsdoc/hifi-jsdoc-template/static/fonts/Graphik-Semibold.otf

0
0
0
⚠ File gone

tools/jsdoc/hifi-jsdoc-template/static/fonts/proximanova-regular.otf

0
0
0
⚠ File gone

tools/jsdoc/hifi-jsdoc-template/static/images/fav-icon.ico

0
0
0
⚠ File gone

tools/jsdoc/hifi-jsdoc-template/static/images/white-logo.png

0
0
0
⚠ File gone

tools/jsdoc/hifi-jsdoc-template/static/styles/jsdoc.css

705
0
705
⚠ File gone

tools/jsdoc/intro.md

7
7
0
6

tools/jsdoc/out/README.md

1
0
1
⚠ File gone

tools/jsdoc/package.json

19
7
12
⚠ 0

tools/jsdoc/plugins/hifi.js

176
0
176
⚠ File gone

tools/jsdoc/plugins/hifiJSONExport.js

19
0
19
⚠ File gone

tools/jsdoc/plugins/tivoli-json-export.js

25
25
0
⚠ File gone

tools/jsdoc/plugins/tivoli.js

150
150
0
⚠ File gone

tools/jsdoc/root.js

12
1
11
1

tools/jsdoc/template/publish.js

956
956
0
941

tools/jsdoc/template/static/fonts/roboto-mono-v7-latin-700.eot

0
0
0
182

tools/jsdoc/template/static/fonts/roboto-mono-v7-latin-700.svg

0
0
0
390

tools/jsdoc/template/static/fonts/roboto-mono-v7-latin-700.ttf

0
0
0
162

tools/jsdoc/template/static/fonts/roboto-mono-v7-latin-700.woff

0
0
0
134

tools/jsdoc/template/static/fonts/roboto-mono-v7-latin-700.woff2

0
0
0
108

tools/jsdoc/template/static/fonts/roboto-mono-v7-latin-regular.eot

0
0
0
152

tools/jsdoc/template/static/fonts/roboto-mono-v7-latin-regular.svg

0
0
0
390

tools/jsdoc/template/static/fonts/roboto-mono-v7-latin-regular.ttf

0
0
0
144

tools/jsdoc/template/static/fonts/roboto-mono-v7-latin-regular.woff

0
0
0
122

tools/jsdoc/template/static/fonts/roboto-mono-v7-latin-regular.woff2

0
0
0
132

tools/jsdoc/template/static/fonts/roboto-v20-latin-700.eot

0
0
0
156

tools/jsdoc/template/static/fonts/roboto-v20-latin-700.svg

0
0
0
309

tools/jsdoc/template/static/fonts/roboto-v20-latin-700.ttf

0
0
0
502

tools/jsdoc/template/static/fonts/roboto-v20-latin-700.woff

0
0
0
133

tools/jsdoc/template/static/fonts/roboto-v20-latin-700.woff2

0
0
0
129

tools/jsdoc/template/static/fonts/roboto-v20-latin-regular.eot

0
0
0
146

tools/jsdoc/template/static/fonts/roboto-v20-latin-regular.svg

0
0
0
308

tools/jsdoc/template/static/fonts/roboto-v20-latin-regular.ttf

0
0
0
498

tools/jsdoc/template/static/fonts/roboto-v20-latin-regular.woff

0
0
0
137

tools/jsdoc/template/static/fonts/roboto-v20-latin-regular.woff2

0
0
0
137

tools/jsdoc/template/static/images/favicon.png

0
0
0
297

tools/jsdoc/template/static/images/logo.png

0
0
0
309

tools/jsdoc/{hifi-jsdoc-template => template}/static/scripts/collapse.js

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/static/scripts/jquery-3.1.1.min.js

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/static/scripts/linenumber.js

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/static/scripts/prettify/Apache-License-2.0.txt

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/static/scripts/prettify/lang-css.js

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/static/scripts/prettify/prettify.js

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/static/scripts/search.js

0
0
0
⚠ File gone

tools/jsdoc/template/static/styles/jsdoc.scss

811
811
0
797

tools/jsdoc/{hifi-jsdoc-template => template}/static/styles/prettify.css

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/augments.tmpl

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/container.tmpl

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/description.tmpl

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/details.tmpl

2
1
1
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/example.tmpl

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/examples.tmpl

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/exceptions.tmpl

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/layout.tmpl

61
9
52
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/mainpage.tmpl

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/members.tmpl

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/method.tmpl

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/methodList.tmpl

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/paramList.tmpl

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/params.tmpl

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/properties.tmpl

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/returns.tmpl

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/returnsSimp.tmpl

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/signal.tmpl

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/signalList.tmpl

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/source.tmpl

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/tutorial.tmpl

0
0
0
⚠ File gone

tools/jsdoc/{hifi-jsdoc-template => template}/tmpl/type.tmpl

0
0
0
⚠ File gone

80 files
-
4664
2009
2655
6737

To work on this, please assign the issue to yourself, then look at the commit and decide whether this would be a good addition to Overte.

If the commit is useful, tag it with "Tivoli: Keep", and keep it open until it's merged.
If the commit is not useful, tag it with "Tivoli: Discard", and close it.
If the commit is not useful right now, but might be later, tag it with "Tivoli: Maybe later", and close it.
If it's hard to decide, tag it with "Tivoli: Discuss", and keep it open.

Useful commits should be submitted as a PR against Overte. Tag this issue in PR, so that it's automatically closed once the PR is merged.
You can cherry-pick this issue with this command:
git cherry-pick 70653ac1e8ed2f82baaa2485f8af3bed17c4ba7e

I will have to go through it at some point.


Update Documentation Workflow's Header Comments

As of right now, docs.yml still mentions adrdox.
# Builds the documentation, with the latest adrdox, with every push to master,
# and deploys it to the gh-pages branch. Derived from Paul Backus'
# https://github.com/pbackus/sumtype/blob/master/.github/workflows/docs.yml.

The whole thing should probably just be truncated to state the file's origins since the workflow is straightforward (for now) and has comments where needed.

Yep, thanks! I will fix this when I get a chance.


Demo readme: update FPGA screencast url

Updated url to point to the FPGA screencast with a Legal Disclaimer.

Codecov Report

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

@@          Coverage Diff           @@
##           master    #118   +/-   ##
======================================
  Coverage    79.7%   79.7%
======================================
  Files          10      10
  Lines        1212    1212
======================================
  Hits          966     966
  Misses        223     223
  Partials       23      23

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 c54b5e1...6d97ad4. Read the comment docs.


Add const MACBYTES to public API

Without it in sodiumoxide's public API one has to depend directly on libsodium-sys

Use case: https://github.com/zetok/tox/commit/12b19f38304ec7ed90521b62efd75c798a64ed9b#diff-73e23c45f37e2a75ffd0ca705fa56a09R404

I'll merge as soon as I have the chance...

Ok, thanks :)

I need you to agree to the license changes in #102 before merging, is that ok with you?


lightdm/plasma5: after suspend no username and password field is shown

Issue description
After sudo systemctl suspend, and getting it out of sleep again, no username and password field is shown until I press Control-Alt-F1 and then Control-Alt-F7.
Any possible fix should be backported to 18.09.
Technical details

system: "x86_64-linux"
host os: Linux 4.14.93, NixOS, 18.09.git.749a3a0 (Jellyfish)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.1.3
channels(root): "nixos-18.09.1571.7795a7ad5f0"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Please report whether this is still an issue.


Add validateInput() hook to AdminUI Fields on Item Details page

fixes https://github.com/keystonejs/keystone-5/issues/1222
validateInput takes similar parameters to the the server-side validation hook, with one addition addFieldValidationWarning():
https://github.com/keystonejs/keystone-5/blob/admin-ui-client-hooks/packages/fields/src/Controller.js#L24-L57
The different between warnings and errors:

Errors disable saving altogether.
Warnings disable saving on the first try. Subsequent tries (without any edits) will save.
If the user edits any fields after an error or warning is raised, validateInput() will be run again and the cycle start over.

Errors

Warnings

@jesstelford this PR is ready 😄

We should consider https://github.com/keystonejs/keystone/issues/4787

@VinayaSathyanarayana that's a great suggestion! Can you open an issue on this repo so we don't lose track of the idea? Thanks 👍

@jesstelford we should have 4 styles for the flags - success, info, warning and error
Based on a visual review of the gifs you included (awesome you added them 👏) I think it should be clearer when there's an error that blocks submitting the form vs. a warning that you can override.
Let's use the red error style for errors, and the orange warning style for warnings
(If the videos are out of date and you subsequently did this, disregard, I'm just starting the code review now)


Allow explicit skips in batch mode

Description
Batch mode is extremely useful for testing a change hasn't impacted the behavior of any samples (say, but crashing or producing a black screen).
However, if there are known crash issues in examples (that are present on the main branch) such as #913  then batch mode only becomes useful until you hit that broken example.
This change adds a flag that allows batch mode to skip examples by id that would normally be included otherwise.
General Checklist:
Please ensure the following points are checked:

[X] My code follows the coding style
[X] I have reviewed file licenses
[X] I have commented any added functions (in line with Doxygen)
[X] I have commented any code that could be hard to understand
[X] My changes do not add any new compiler warnings
[X] My changes do not add any new validation layer errors or warnings
[X] I have used existing framework/helper functions where possible
[X] My changes do not add any regressions
[X] I have tested every sample to ensure everything runs correctly
[X] This PR describes the scope and expected impact of the changes I am making

Note: The Samples CI runs a number of checks including:

[X] I have updated the header Copyright to reflect the current year (CI build will fail if Copyright is out of date)
[X] My changes build on Windows, Linux, macOS and Android. Otherwise I have documented any exceptions

Fixes #936

The CLI11 fix is already a distinct commit.  I think making a whole distinct PR for it might be excessive.


Frequency detection documentation is confusing.

I just had a look at the frequency detection code to find out what its purpose is.
Reading the documentation is not very enlightening: Detects if a points occurs multiple times within a defined time range
Reading the code, doesn't really help either:

It takes multiple time series as arguments, but only looks at the first one.
It uses the List<Long> currentWindow as a counter (just the size, contents irrelevant).
It seems to subdivide a timeseries into chunks just smaller than windowSize minutes in duration and returns true if a chunk has at least windowThreshold more observations than its predecessor.

I agree - the documentation at this point is poor...
The frequency detector splits a time series into windows, counts the data points, and checks if the delta
between two consecutive windows is above a predefined threshold.

Also see #42 and #60


Live update stops working with frames containing large number of layers

When I paste a frame with 389 layers into document, live updates stops working. Frame contains only vectors so file size shouldn't be an issue.
Restarting the application doesn't seem to help. No errors in Logcat either. Design switcher status shows old version of document.
I got it to update once, but after that Live update stopped again.

Hi there. Sometimes this happens when something in the 389 layers has some kind of newer Figma property set that we don't yet support yet and fail to parse, causing deserialization of the Figma file to fail. Does the DesignSwitcher show any errors if you open it up? This is the little arrow at the top right that shows some live update info if you open it up like this:

If you don't see anything there, is it possible to share a Figma document with the layers that cause this problem? Alternatively you could try taking subsets of those 389 layers to narrow down which part causes the problem.

Hi. No errors in DesignSwitcher.

But this time I got some errors in logcat.

Seems like some components are not accessable. Can this be because they are from shared file ?
Unfortunately I am unable to share the document because of NDA.

Those errors mean that those nodes in your Figma documents are instances of components defined in other files. When DesignCompose comes across those types of nodes, it tries to download the full component from the other file, but sometimes fails for some reason (no access, original component has been deleted, etc). That's what look like has happened here. However, it usually does not cause an issue. The issue is logged to logcat, but it continues with the rest of the Figma document and renders what it can, so I don't think that is the issue here.
From what I see here, live update is still working. I don't know what is in all those layers you are copying, but without being able to see it I would suggest trying to break it down into smaller parts to see if it's a particular layer causing a problem. If you're able to reproduce this with a set of layers in a test doc not under NDA it would also be helpful and I can take a look.

I tried to figure out what could be causing this issue. And found out, that Live update works fine, but the fetch/parse takes too long (~4 min for component containing 3 icons).

*images are blurred because of NDA
The component its fetching has 3 visible icons and another 8 hidden. All of them have 5 different variants. All of these components also have to be fetched from different file.
When I inserted a whole screen containing 389 layers the fetch/parse took so long I though that the Live update was broken.

@FruitSnack1 I think this could also be caused by components referenced from the layers being in other documents. In that case, DesignCompose fetches the referenced documents and also processes those in order to extract the full components (in case they have variants, etc).
We're going to add some logging to surface things that could take a long time during fetch (#281), so hopefully in a future release you'll be able to repro and we can find out what to do to make a fix.

Just figured out a quick solution.
In Figma you can detach all instances (turn components into frames, shapes, ...).
Without all the components and variants from different files, live update works normal and updates in matter of seconds, event with frames containing hundreds of layers.
To "detach all instances":

Select all elements you want to detach
Press Ctrl + /   (Command + / on mac)
Run the "Detach all nested instances" command

Ok, excellent. Are you using Figma's Design Library feature? We're wondering if we should restrict recursive doc fetching only to situations where a Design Library is in use (which would also limit the number of docs that must be fetched).

Yes we do.


Use a maven proxy for integration tests to speed them up

Experiment with mrm plugin

Let me try to fix this.

Do the durations and impl. look acceptable to you @gnodet ?

When comparing to this recent build there is a consistent improvement by ~1.5 min across all OSes.

@ppalaga awesome ! thx


Roll engine 953ac71749ee..86d1452baf2d (1 commits)

git@github.com:flutter/engine.git/compare/953ac71749ee...86d1452baf2d
git log 953ac71749ee..86d1452baf2d --no-merges --oneline
2019-09-24<EMAIL_ADDRESS>Roll src/third_party/skia c096654fa7c6..867ab81687fc (4 commits) (flutter/engine#12417)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

AutoRoller is stopped; closing the active roll.


Add iterator for instrumentation/extension packet arbitration and decoding

Refer to https://github.com/rtic-scope/itm-decode/issues/19.

Ideally, the API should allow us to add an adapter upon iter::{Timestamps,Singles}.

itm-decode should also be extended to support decoding of strings in these packets.


Will return list() for anything Falsey (instead of only for None)

https://github.com/friedererdmann/pymxs_stubs/blob/84d410c46d4718d7c0928574d12740100574a947/pyi_generator.py#L10

Thanks for spotting this! Will get to it asap

fixed in 4c6ca407a4f879f708c6f63ed9f22cc6ec74b64e


Add python-tqdm dependency for progress bars

See corresponding issue #15561 for motivation, use cases, and links to web listings for this package.
This is my first pull request into this repo. Please let me know if there's any changes or more information needed as I would like to get this in soon. :smile:

this looks good!
A few remarks:

ros packages can be released only if its dependencies are available via the default package manager (e.g. apt for ubuntu and debian). As it stands, tqdm being available in apt only since yakkety, you will not be able to release a package depending on this in any of the existing ROS distributions (please see REP3 for the list of targeted platform for each ROS diistribution)

Though you will be able to use this key to build from source

We don't have any "alive" ROS Distribution targetting ubuntu versions older than Ubuntu Saucy (Indigo), if you are not planning on building from source on platform older than Saucy there is no need to add a rule for it

@mikaelarguedas I only added python-tqdm to make dependency management easier for source building and currently don't have any plans to release binaries in the near-term. The lack of ability to distribute it in binaries should be fine for my use case.
I've deleted the key-value pairs for the old Ubuntu versions in b92447c.

Could this go in? I'm setting up CI for my project now which would be a lot simpler if this were in.

Rosdep keys need 2 approvals to get merged, a member of the team will review and 'squash and merge' this PR soon

Thanks for showing me the ropes and for the quick turnaround times @mikaelarguedas and @dirk-thomas!


Update 04_iteration.md

Making sure that example code runs.

This is another example that follows the principle that the docs and examples default to the syntax enabled by the nightly feature, and that using the stable syntax requires a few small changes because on non-nightly, signals can't implement the Fn traits.
It's becoming clearer over time to me that we will need to rewrite the docs in the future to use the stable syntax by default, which makes me sad because I think it's worse than the nightly approach. I don't know that changing one instance is the right way to do that, although it may be the case that we have adapted enough of the APIs that there are not other places that are broken in the docs.

Thanks for the clarification. I am on latest stable and overlooked that the example might be based on nightly.

From: Greg Johnston @.>
Sent: Saturday, February 17, 2024 12:16 AM
To: leptos-rs/book @.>
Cc: Ratul @.>; Author @.>
Subject: Re: [leptos-rs/book] Update 04_iteration.md (PR #66)
This is another example that follows the principle that the docs and examples default to the syntax enabled by the nightly feature, and that using the stable syntax requires a few small changes because on non-nightly, signals can't implement the Fn traits.
It's becoming clearer over time to me that we will need to rewrite the docs in the future to use the stable syntax by default, which makes me sad because I think it's worse than the nightly approach. I don't know that changing one instance is the right way to do that, although it may be the case that we have adapted enough of the APIs that there are not other places that are broken in the docs.
—
Reply to this email directly, view it on GitHubhttps://github.com/leptos-rs/book/pull/66#issuecomment-1949102180, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAM3HOYHSEXE5TENAB7AMW3YT6SPDAVCNFSM6AAAAABDJLQSQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBZGEYDEMJYGA.
You are receiving this because you authored the thread.Message ID: @.***>

Hi Greg,
I was looking at Appendix section - Do you think there is a typo there? Please have a look at the attachment.
[cid:2caf6217-d200-4464-b7ad-e02d377e08ae]

From: Greg Johnston @.>
Sent: Saturday, February 17, 2024 12:16 AM
To: leptos-rs/book @.>
Cc: Ratul @.>; Author @.>
Subject: Re: [leptos-rs/book] Update 04_iteration.md (PR #66)
This is another example that follows the principle that the docs and examples default to the syntax enabled by the nightly feature, and that using the stable syntax requires a few small changes because on non-nightly, signals can't implement the Fn traits.
It's becoming clearer over time to me that we will need to rewrite the docs in the future to use the stable syntax by default, which makes me sad because I think it's worse than the nightly approach. I don't know that changing one instance is the right way to do that, although it may be the case that we have adapted enough of the APIs that there are not other places that are broken in the docs.
—
Reply to this email directly, view it on GitHubhttps://github.com/leptos-rs/book/pull/66#issuecomment-1949102180, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAM3HOYHSEXE5TENAB7AMW3YT6SPDAVCNFSM6AAAAABDJLQSQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBZGEYDEMJYGA.
You are receiving this because you authored the thread.Message ID: @.***>


refactor: fix #148

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Evaluation workflow

The results of throughput and latency measurement are stored in the TaskManager's .out file in flink/log. Write a script extracting these values and visualize them.

@kevinnguyen20 If the file is not big can you just put in our repo to see the format.


refactor: API initialization

Change to initialize each API endpoint client when it is called

Pull Request Test Coverage Report for Build 70

13 of 13 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.01%) to 99.024%

Totals

Change from base Build 68:
0.01%

Covered Lines:
203

Relevant Lines:
205

💛  - Coveralls


Fix gdkwayland pkg name in README.md snippets

The folder name is gdkwayland so the Cargo.toml snippets should have gdk-wayland = { git = "https://github.com/gtk-rs/gtk3-rs.git", package = "gdkwayland" } instead of gdk-wayland = { git = "https://github.com/gtk-rs/gtk3-rs.git", package = "gdk-wayland" }.
Maybe a comment noting that the package hasn't been released yet and can only be used by the git style should be added too?

The documentation links do not seem to be working either but I cannot find any working link for those. It looks like the dev docs do not have gdk-wayland but I wonder if that is on purpose.

The documentation links do not seem to be working either but I cannot find any working link for those. It looks like the dev docs do not have gdk-wayland but I wonder if that is on purpose.

there is no need to, we are planning to do a release in the upcoming days


Updated rodio from 0.11 to 0.13

Updated rodio.
A breaking change seems to be that devices and audio streams are now two different things. OutputStream now has try_default() and OutputStreamHandle now has play_raw.
The OutputStream must be kept in memory even though we're only interacting with the OutputStreamHandle as per the documentation:
If this (the OutputStream) is dropped playback will end & attached OutputStreamHandles will no longer work.

Changelog: https://github.com/RustAudio/rodio/blob/master/CHANGELOG.md
Commits: https://github.com/RustAudio/rodio/compare/7bf8ba5cb629d419a2bd003f8e8e387b1db1f717..c397a4d8d18402badefddea89b53ed42226adb5e

I've been a bit hesitant to upgrade Rodio, because there's a few regressions listed on their issue tracker that don't seem to have been resolved (one with 'nightmare noises' in the title, which doesn't inspire confidence...). Additionally, I'm very eager to move away from Rodio long term - oddio seems much better designed, and would potentially allow me to hook into SDL2's (very stable, iirc) audio backend for IO.
Is there anything specific from Rodio 0.12/0.13 that you're missing? If so, I'll probably do the upgrade as a stopgap :)

Is there anything specific from Rodio 0.12/0.13 that you're missing?

No, I noticed vek was outdated and went to see how much effort it was to update that, and I ended up making a PR for every outdated dependency. If you want to keep rodio at 0.11 that's perfectly fine

:+1: I'll keep the Dependabot PR open so I don't forget about it, either way.
Also, this PR made me notice that the path is wrong in the audio example, so not a waste of time 😄


SKTD: Knowledge Transfer Document - Documentation Infrastructure

@christianguenter2 can you help adding a few hints? I'm not sure how to create this thing in SE80
just trying to move the issue forward

@larshp It's not possible to create the KTD in SE80 as it seems - one has to use ADT. You even can't open these objects in SE80 as it will state that you should please open it in ADT^^.

Seems like it was already implemented by SAP in ABAP in the cloud as CL_ABAPGIT_OBJECT_SKTD.


Fix Auth Dogfooding Bugs

Please fix bugs 22 and 23 on the dogfooding doc

/cib fix auth bugs

Branch 112-fix-auth-bugs created!


Application Gateway - CanceledAndSupersededDueToAnotherOperation issue

We have an Application Gateway that we're using with several teams.
Obviously, we have setup several CI/CD pipelines (with using the AZ CLI) that deploy our resources and creates our entrypoint for the Application Gateway.
We have started to notice that when we run several commands against the gateway (at the same time), we get the following error:
ERROR: (Canceled) Operation was canceled.
Code: Canceled
Message: Operation was canceled.
Exception Details:	(CanceledAndSupersededDueToAnotherOperation) Operation PutApplicationGatewayOperation (6cc97f54-b83d-46cd-83eb-be3b71a87b39) was canceled and superseded by operation PutApplicationGatewayOperation (f1138d5e-3e2c-4592-b178-b9655c5e1033).
	Code: CanceledAndSupersededDueToAnotherOperation
	Message: Operation PutApplicationGatewayOperation (6cc97f54-b83d-46cd-83eb-be3b71a87b39) was canceled and superseded by operation PutApplicationGatewayOperation (f1138d5e-3e2c-4592-b178-b9655c5e1033).
Returncode: 1

We've tested this and it seems to be that indeed, the first request gets cancelled, which ends in a failed pipeline and no entrypoint created for the Application Gateway. This keeps us from being able to run our pipelines at the same time, since it often ends in an error. We've been running these pipelines for the last few years, but haven't noticed this behaviour before.
The az cli commands that we're using are all part of the az network application-gateway endpoints, for example:

az network application-gateway address-pool create
az network application-gateway probe create

I would expect that I would be able to add/update several listeners/backend pools/etc for the gateway at the same time, without the first operation being cancelled.
So the question we have is:
Did something change with these calls?
Is this the expected behaviour?
And could someone explain why this is/should be the case?

I faced the same issue, in my case, I am using Terraform with the null_resource:
resource "null_resource" "external_appgw_assign_identity" {
  count = var.kv_certificates_integration ? 1 : 0

  # A new external application gateway requires re-provisioning
  triggers = {
    external_application_gatewy_id = azurerm_application_gateway.external_appgw.id
  }

  provisioner "local-exec" {
    command = "az network application-gateway identity assign --gateway-name ${local.external_gateway_name} --resource-group ${local.external_gateway_rg_name} --identity ${local.external_agic_identity_id} --subscription ${data.azurerm_subscription.primary.subscription_id}"
  }
}

But is odd because I have deployed my Terraform module multiple times and today is the first time that I face that issue...
Then I deployed from scratch an AKS Cluster with my Terraform module and the deployment was completed without errors.
Should I insert some kind of delay (like time_sleep) to avoid the issue?

It seems that service side has some adjustments in handling concurrent operations against application gateway. Thanks.

@necusjz Thank you for your comment.
Please advise how to handle these changes. I cannot find a specific locking mechanism to lock the Application Gateway when another operation is being handled (as for example, creating a listener).
Hope to hear from you!

@LotteVoorhorst Let's wait for the feedback from service side. : )
From CLI side, we can append --no-wait argument, like:
az network application-gateway probe create -n {} -g {} --gateway-name {} --path {} --protocol {} --host {} --no-wait

@necusjz  Can you confirm that this workaround helps?

@necusjz Can you confirm that this workaround helps?

@ddran-averydennison FYI: I have simulated the scenario of creating probes concurrently on my local machine and it worked.

I've tried the --no-wait option, but unfortunately I'm getting the next error when concurrently creating domain entrypoints:
Invoke-Executable az network application-gateway rule create --gateway-name {gateway-name} --name {name} --resource-group {resourcegroup} --http-listener {name} --rule-type Basic --redirect-config {redirect-config} --no-wait
ERROR: (RetryableError) A retryable error occurred.
Code: RetryableError
Message: A retryable error occurred.
Exception Details:	(RetryableErrorDueToAnotherOperation) Operation PutApplicationGatewayOperation (8ce638ea-c314-4d26-a304-d9903d49e5cd) is updating resource {resource-id}. The call can be retried in 12 seconds.
Code: RetryableErrorDueToAnotherOperation
Message: Operation PutApplicationGatewayOperation (8ce638ea-c314-4d26-a304-d9903d49e5cd) is updating resource {resource-id}. The call can be retried in 12 seconds.
Returncode: 1
It's a different error, but still the same problem. This should not happen when using the 'no-wait' option, correct?
Please advise how to handle.

@HemantErappa , it seems that service side has some adjustments in handling concurrent operations against application gateway. Could you give us a hand? Thanks!

Any updates on this issue?

@yonzhan @necusjz @HemantErappa  - Do you have any update on when this may be looked into on the service side at all?

I am also receiving the same issue, has anyone been able to resolve this?

Updates:
I have contacted with the service team. "CanceledAndSupersededDueToAnotherOperation" means if customer performed multiple PUT operations in quick succession on the same appgw resource, then the previous one gets cancelled and superseded by the new one.
So, it's expected and by design. We can add some time sleeps to wait for previous PUT calls to complete as a workaround.

I just came across this.  I still believe there is an issue.  I am trying to create an application gateway using the cli and it runs for about 2 minutes and then gets cancelled.  I am running it manually and there are no other operations being sent.  When looking at the deployment details in the resource group I find I get the same error posted above.  This was a single create request that generated this error.
 "statusMessage": "{\"status\":\"Canceled\",\"error\":{\"code\":\"ResourceDeploymentFailure\",\"message\":\"The resource operation completed with terminal provisioning state 'Canceled'.\",\"details\":[{\"code\":\"Canceled\",\"message\":\"Operation was canceled.\",\"details\":[{\"code\":\"CanceledAndSupersededDueToAnotherOperation\",\"message\":\"Operation PutApplicationGatewayOperation (c274d748-3495-4a91-b6d7-0b9d76fc4102) was canceled and superseded by operation PatchApplicationGatewayOperation (236ea644-bb1c-43b8-b915-cd6beb13a31b).\"}]}]}}",

I'm also still experiencing this, we're using terraform and not doing anything fancy at all. It appears to be happening during a destroy operation. Blocks the destroy.
Why are these operation not just queued? Seems like the logical way to handle it rather than cancelling.

Today I cam across this issue when I tried to create a VNET through azapi provider as I needed to use IPAM Pool. I created the VNET first and tried adding subnets iteratively but I face with the same issue
{
"status": "Canceled",
"error": {
"code": "Canceled",
"message": "Operation was canceled.",
"details": [
{
"code": "CanceledAndSupersededDueToAnotherOperation",
"message": "Operation PutSubnetOperation (6da3da81-f6c7-421f-9e56-0d6785c8e2ba) was canceled and superseded by operation PutSubnetOperation (dbe8e72d-09ce-407f-bf57-30a1e1ee8bdc)."
}
]


As a user, I'd like stack traces from the managed NPSP package to be available to the user

Ideally, these would be available in the custom error log and custom error notifications.
Alternatively, we could think wether to send error information (with stack traces) data back from the LMO to the originating org. Maybe we could use Salesforce-to-Salesforce (https://developer.salesforce.com/page/An_Introduction_to_Salesforce_to_Salesforce). If that is not available, we could send a message to a web service we create to process errors sent from the LMO.

**lurch: attach W-007281

Tracking W-007281


cargo test --doc does not respect CARGO_BUILD_JOBS env variable

Problem
I use a global variable CARGO_BUILD_JOBS=4 because the default configuration results in my machine running out of memory when compiling some rust projects. However recently I noticed that this fails when there are many doc tests in the project, because it looks like all the doc tests are compiled in parallel.
Steps

Find some project with many doc tests
export CARGO_BUILD_JOBS=1
cargo test --doc
In a separate terminal, run pidof rustc and notice how there are as multiple processes, instead of the expected 1.
This results in the tests failing, in my case because the linker is killed because the system has run out of memory.

Possible Solution(s)
In my opinion the correct behavior is to respect CARGO_BUILD_JOBS when compiling the tests.
As a workaround, you can use
cargo test -- --test-threads 1

to limit the number of build jobs to 1, however this also affects normal tests, so running tests will be much slower.
Notes
No response
Version
cargo 1.61.0 (a028ae4 2022-04-29)
release: 1.61.0
commit-hash: a028ae42fc1376571de836be702e840ca8e060c2
commit-date: 2022-04-29
host: x86_64-unknown-linux-gnu
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.80.0-DEV (sys:0.4.51+curl-7.80.0 vendored ssl:OpenSSL/1.1.1m)
os: Ubuntu 22.04 (jammy) [64-bit]

To my understanding, rustdoc collects each doctest and compiles them by invoking rustc on-the-fly^1, and that is a part of test fn^2, which will be executed by libtest.
That tells us why build.jobs (controls cargo-rustc jobserver) doesn't affect parallelism of doctest, but --test-threads does (controls parallelism of libtest).

I would recommend opening an issue against rust-lang/rust, though I don't have any viable fix for rustdoc in mind at this moment 😞. In the meanwhile, I suggest you to stick with cargo test --doc -- --test-threads 1 in order not to affect unit/integration tests.
Closing as the behaviour is controlled by rustdoc. Cargo gets no knowledge about how a test fn being executed. If you think this issue shouldn't be closed, feel free to reopen and discuss further. Thanks :)

@weihanglo I disagree with your assessment, rustdoc has no knowledge of cargo and it's environment variables and shouldn't have any.
If cargo want to control the number of test parallelism with it's env CARGO_BUILD_JOBS it should pass the right command line argument to rustdoc.
I would also argue that CARGO_BUILD_JOBS shouldn't control this at all. Yes, technically rustdoc build something but it's irrelevant, it's testing: testing isn't the same as building.

Hmm… Sorry about the misleading. I was not suggesting that rustc should recognize CARGO_BUILD_JOBS and I totally agreed CARGO_BUILD_JOBS shouldn't touch how tests are executed. What I wanted to say is that if they want to let Cargo control those rustc invocations from rustdoc tests, they should ask rustdoc for providing such an interface (though that's hard and might be a breaking change).
For now, I feel like it's even not a problem since there is already a alternative solution (cargo test --doc -- --test-threads 1). I shouldn't head them towards opening another issue in rust-lang/rust. @Urgau, sorry for the mistake and not saying it clearer. 😞

Hi @weihanglo, unfortunately that workaround doesn't work, because the tests are compiled again when running the second command. I also tried variations like using --all-features in both commands, but that still causes a crash in the second command.
cargo test --doc --all-features -- --test-threads 1
cargo test --all-features

In my case, the root cause of this issue is that the default configuration results in an out of memory crash. I can fix that by setting the CARGO_BUILD_JOBS variable globally to a lower number of threads. And that fixes the problem everywhere except when running doc tests. So while I understand that because of some implementation details my desired behavior of respecting the CARGO_BUILD_JOBS variable cannot be implemented, I strongly believe that it would be the correct behavior. Because my machine simply cannot handle the full parallelism of rustc, so I would expect a single environment variable to fix that issue globally. Because even if there is a workaround like running two separate cargo test commands, every other person that has a similar problem will also need to run that sequence of commands.

Ok, I see. Whether that there is a change in rustdoc, cargo still needs to integrate with that or implement something on its own. I'll leave this open for tracking any future possibilities.

Hi, I don't know if this has been fixed already, but I saw that the cargo parallel frontend solved this exact same problem using the "jobserver protocol":

You might wonder how interprocess parallelism and intraprocess parallelism interact. If we have 20 parallel rustc invocations and each one can have up to 16 threads running, could we end up with hundreds of threads on a machine with only tens of cores, resulting in inefficient execution as the OS tries its best to schedule them?
Fortunately no. The compiler uses the jobserver protocol to limit the number of threads it creates. If a lot of interprocess parallelism is occuring, intraprocess parallelism will be limited appropriately, and the number of threads will not exceed the number of cores.

Source: https://blog.rust-lang.org/2023/11/09/parallel-rustc.html#putting-it-all-together


fix menu collapses when select DHCP Server interfaces tab

Services -> DHCP Server

@tomcheung789 Thank you for fixing!


WIP: let the user chose the boot disk for multiboot

@bennyz the linking part is still missing, I'm not sure what would be the best way to do it....

@bennyz the linking part is still missing, I'm not sure what would be the best way to do it....

As discussed shouldn't be an issue, we only care about passing the device representing the selected disk to --root


Automated Package Upgrade

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[BigQuery]: Makes BigQueryRow.TimestampConverter support dates pre 1970.

Fixes #4821

Thanks! Will wait on green before merging.