报错：500

Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/flask/app.py", line 2528, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python3.9/site-packages/flask/app.py", line 1825, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/usr/local/lib/python3.9/site-packages/flask/app.py", line 1823, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python3.9/site-packages/flask/app.py", line 1799, in dispatch_request
return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)
File "/app/app.py", line 12, in hello_world
max_results = int(request.args.get('max_results')) or 3
TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType'

[2023-05-10 05:53:10,149] ERROR in app: Exception on /search [GET]
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/flask/app.py", line 2528, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python3.9/site-packages/flask/app.py", line 1826, in full_dispatch_request
return self.finalize_request(rv)
File "/usr/local/lib/python3.9/site-packages/flask/app.py", line 1845, in finalize_request
response = self.make_response(rv)
File "/usr/local/lib/python3.9/site-packages/flask/app.py", line 2137, in make_response
raise TypeError(
TypeError: The view function for 'search' did not return a valid response. The function either returned None or ended without a return statement.


Support Apple Silicon Universal

Preflight Checklist

[x] I have read the contribution documentation for this project.
[x] I agree to follow the code of conduct that this project follows, as appropriate.
[x] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem Description
Now I can build mas/arm64 package using --arch=arm64. But I want to build universal package.
Proposed Solution
Add universal as arch parameter, and build universal Electron package. Refs: https://github.com/electron/universal
Alternatives Considered

Additional Information
See also https://github.com/electron/electron/issues/26710

I'm generally not inclined to add support for this in Electron Packager itself. Adding a universal arch to Electron Packager would make the complexity of this Node.js module increase significantly. My feeling is that @electron/universal needs to be a part of the build system after Electron Packager has run. For example (not tested, partially based on the @electron/universal README):
const glob = require('glob')
const { makeUniversalApp } = require('@electron/universal')
const packager = require('electron-packager')
const path = require('path')

// Assumes support for top-level await, if it doesn't exist for the version of Node.js
// you're using, wrap in an async function.

const commonOptions = { /* common Electron Packager options here */ }

const arm64Path = await packager({
  ...commonOptions,
  platform: 'darwin',
  arch: 'arm64'
})[0]

const x64Path = await packager({
  ...commonOptions,
  platform: 'darwin',
  arch: 'x64'
})[0]

const arm64AppPath = glob.sync(path.join(arm64Path, '*.app'))[0]
const x64AppPath = glob.sync(path.join(x64Path, '*.app'))[0]
const universalApp = path.basename(x64AppPath)

await makeUniversalApp({
  arm64AppPath,
  x64AppPath,
  outAppPath: universalApp,
});

for anyone that stumbles upon this, support was added here. There is now a universal arch option that can be used.

I am running into an issue with arch="universal" where we have a universal binary being included in the app package.
Stitching universal app for platform darwin
Detected file "Contents/Resources/app/app/projectGenerator" that's the same in both x64 and arm64
builds and not covered by the x64ArchFiles rule: "undefined"

Can anyone explain how I can set the variable: x64ArchFiles
I have tried setting it as an arg here, but I am not sure electron-packager is even passing it on to @electron/universal?
"build:macos": "electron-packager . $npm_package_productName --icon=static/icon/of.icns --out=dist --ignore='dist' --ignore='readme.md' --prune --overwrite --electron-version=24.1.2 --platform=darwin --arch=universal --x64ArchFiles=Contents/Resources/app/app/projectGenerator"
Or what is the correct way to pass osxUniversal options via a build command ( this is in our package.json )
"build:macos": "electron-packager . $npm_package_productName --icon=static/icon/of.icns --out=dist --ignore='dist' --ignore='readme.md' --prune --overwrite --electron-version=24.1.2 --platform=darwin --arch=universal --osxUniversal={x64ArchFiles:'Contents/Resources/app/app/projectGenerator'}",
Or is there any other way I can have the file be included for just one of the builds before they are joined so it doesn't error?
Related:
https://github.com/electron/universal/pull/47

so changing this function too:
from:
  await universal.makeUniversalApp({
    ...comboOpts.osxUniversal,
    x64AppPath: path.resolve(x64AppPath, appName),
    arm64AppPath: path.resolve(arm64AppPath, appName),
    outAppPath: path.resolve(universalStagingPath, appName)
  })

to:
  await universal.makeUniversalApp({
    ...comboOpts.osxUniversal,
    //add this line to pass through x64ArchFiles to be excluded from lipo
    x64ArchFiles : comboOpts.x64ArchFiles,
    x64AppPath: path.resolve(x64AppPath, appName),
    arm64AppPath: path.resolve(arm64AppPath, appName),
    outAppPath: path.resolve(universalStagingPath, appName)
  })

allows me to build a universal app by adding the x64ArchFiles option to the build:
    "build:macos": "electron-packager . $npm_package_productName --icon=static/icon/of.icns --out=dist --ignore='dist' --ignore='readme.md' --prune --overwrite --electron-version=24.1.2 --platform=darwin --arch=universal --x64ArchFiles=Contents/Resources/app/app/projectGenerator",

It definitely doesn't feel like an elegant solution, I think there should be a way to do this via OsxUniversalOptions but there doesn't seem to be any documentation on how to do that.
Apologies for the noise also, it is just quite a breaking issue for us, and the documentation here seems lacking.

Hey @ofTheo,
In the electron-packager config, osxUniversal is the actual option name while OsxUniversalOptions is the TypeScript type of the object structure. Hope this points you in the right direction!
https://electron.github.io/electron-packager/main/interfaces/electronpackager.options.html#osxuniversal

Thanks for the reply @erickzhao !
What would be the correct way to get x64ArchFiles set via the osxUniversal option?
It's quite hard to tell how to pass the variable through though to avoid the error.
Trying:
 "build:macos": "electron-packager . $npm_package_productName --icon=static/icon/of.icns --out=dist --ignore='dist' --ignore='readme.md' --prune --overwrite --electron-version=24.1.2 --platform=darwin --arch=universal  --osxUniversal=x64ArchFiles:Contents/Resources/app/app/projectGenerator"
Logging the comboOpts.osxUniversal
  console.log("universal options are:");
  console.log(comboOpts.osxUniversal);

I do see
universal options are:
x64ArchFiles:Contents/Resources/app/app/projectGenerator

But I still get the error about:
not covered by the x64ArchFiles rule: "undefined"
I'm sure it must be a formatting issue ( hopefully ), but the only thing that has worked so far is manually adding that line in universal.js as in my previous comment.
Thanks so much!
Theo

Amazing!
Thank you @erickzhao - it works!!
Really appreciate the help.  🙏

The documentation around this could definitely be clearer, though!

Oh yes, I am guessing a lot of people might run into this. A quick note or example in the docs would definitely be helpful.
It's a shame it is needed at all as I think the default behavior of electron/universal should just be to ignore universal binaries that are identical instead of erroring.  But great we can pass it in here, I can remove my sed hack now 😊

I also opened https://github.com/electron/electron-packager/pull/1533 as I noticed that this was missing from the CLI's usage.txt.
Thanks for bringing this up @ofTheo!

Does anyone know how to add multiple paths to this arg?
I have tried anything, but it only works with one path. From a yargs perspective I have to add the same arg twice:
--osxUniversal.x64ArchFiles=Contents/Resources/somefile --osxUniversal.x64ArchFiles=Contents/Resources/otherFile
but then I got "invalid pattern"


Enable revision and history

This is the relevant change here.

@elbotho Can you take a look if theses changes are fine?

Not entirely sure about this part:
https://github.com/serlo/serlo.org-cloudflare-worker/blob/78ab9b1081c80650ff0b50506ecd55d360cd2457/src/utils/url.ts#L37-L43
Just to make sure:
/^\/entity\/repository\/history\/\d+$/ does use a uuid but since it's not an default alias we have to add it here right?
And the repository/compare links (e.g. /entity/repository/compare/1565/162707) are the default view for a revision uuid so we don't have to add it, right?

You are right, /^\/entity\/repository\/history\/\d+$/ is refering to a uuid, but is not an alias.
In contrast, /entity/repository... is an alias itself, because revisions are uuids.


Animation disable

Wondering if its possible to disable the animate at the beginning of the loading.
Instead of loading the graph, I wanted to have it loaded immediatly without a delay.
I found thus far: Chart.defaults.global.animation but I have no idea how to implement it.
The reason why I want this is because i'm trying to implement this on the mobile phone, and it seems to be quick, but the animation itself the small second it takes to move the graph around seems to be slow.
Is there any way to disable it?

This should work:
options: {
    animation: {
        duration: 0,
    }
}

@zachpanz88 is correct.

Thanks for the quick reply!

I'm trying to disable the animation of the width and height of the chart on resize... I cant seem to figure out how to do this

I wish to obtain an instant rendering, no animation, no empty canvas (I have a div with style 'display:none' and when I show it, the graph should appears with no transition or construction visible). Seems that this is impossible with Chart.js.

I wish to obtain an instant rendering, no animation, no empty canvas (I have a div with style 'display:none' and when I show it, the graph should appears with no transition or construction visible). Seems that this is impossible with Chart.js.

Maybe if you give it animation duration of 0 and then use a onComplete hook to make the chart visible?

Still a problem for me as well. Setting duration:0 seems to speed up the animation, but not prevent it. On first load, there is animation that is taking time and distracting. Wish the width/height wasn't something that animated on first load.

2 years later no solution?

Any updates on the last post here?
I just implemented ChartJS into my project and cannot disable the initial animation.


run sizeColumnsToFit() after loading ag-grid table

I've tried to run ag-grid api in the middle of function, but it doesn't work as I expected. Is there any way to do it?
My scenario is 1) load up the page first, 2) read the data, 3) run API function
So, here's my try, but I have no luck to run api. Any ideas?
import asyncio
import justpy as jp

grid_options = """
{
    rowSelection: 'multiple',
    defaultColDef: {
        filter: true,
        sortable: true,
        resizable: true,
        cellStyle: {textAlign: 'center'},
        headerClass: 'font-bold',
        sizeColumnsToFit: true
    },
      columnDefs: [
      {headerName: "Make", field: "make"},
      {headerName: "Model", field: "model"},
      {headerName: "Price", field: "price"}
    ],
      rowData: [
      {make: "Toyota", model: "Celica", price: 35000},
      {make: "Ford", model: "Mondeo", price: 32000},
      {make: "Porsche", model: "Boxter", price: 72000}
    ]
}
"""

async def grid_test():
    async def read_data(self, msg):
        # spinner on
        self.spinner.showing = True
        await msg.page.update()
        await asyncio.sleep(3)

        # read data
        self.grid.options = grid_options

        # column to fit? doesn't work
        await self.grid.run_api('sizeColumnsToFit()', msg.page)
        await grid.run_api('sizeColumnsToFit()', msg.page)
        await self.grid.run_api('sizeColumnsToFit()', wp)
        await grid.run_api('sizeColumnsToFit()', wp)
        click_to_fit

        # spinner off
        self.spinner.showing = False

    async def click_to_fit(self, msg):
        await self.grid.run_api('sizeColumnsToFit()', msg.page)

    # load up the page first
    wp = jp.QuasarPage()
    grid = jp.AgGrid(a=wp, style='height: 200px; width: 1500px; margin: 0.25em')
    wp.grid = grid
    spinner = jp.QInnerLoading(showing=False, a=wp)
    wp.spinner = spinner

    # read the data
    wp.on("page_ready", read_data)
    wp.on("click", click_to_fit)
    return wp

jp.justpy(grid_test)

I think the click_to_fit line inside read_data line needs to be changed to:
await click_to_fit(self, msg)

Thanks for the answer, but it didn't work.. I changed like this, but api function doesn't work.
    async def read_data(self, msg):
        # spinner on
        self.spinner.showing = True
        await msg.page.update()
        await asyncio.sleep(3)

        # read data
        self.grid.options = grid_options

        # column to fit? doesn't work
        await click_to_fit(self, msg)

        # spinner off
        self.spinner.showing = False

    async def click_to_fit(self, msg):
        await grid.run_api('sizeColumnsToFit()', msg.page)

An automated version or at least an example would IMHO be good - we have the same problem in
http://ceur-ws-browser.bitplan.com and created "fit" buttons there which work

async def  on_fit(self, msg):
    await asyncio.sleep(0.1)
    await self.grid.run_api('sizeColumnsToFit()', msg.page)

this also works with
wp.on("page_ready", on_fit)

Which is valid workaround for the time being. Please create a new issue / discussion if you'd like to see this as a standard feature of justpy.


fix import in @HasManyBy example

Type of PR:

[ ] Bugfix
[ ] Feature
[ ] Refactor
[ ] Code style update
[ ] Build-related changes
[ ] Test
[X] Documentation
[ ] Other, please describe:

Breaking changes:

[X] No
[ ] Yes

Details
Fix the incorrect import in the @HasManyBy example of the decorator docs.

Thanks for spotting this! 👍


Add Go module support for pipelines.

Changes

This enables Go modules and removes the vendor directory from the
repository.

Removes vendor directory. As a result, switches license notice
generation to go-license.
Forks code generation scripts from respective k8s/knative sources to
allow module aware imports. (I want to fix this upstream sometime in
the future, but for now this is as best as we can do).

This should not result in any change of functionality.
Fixes #1315, #1538
This change is dependent on https://github.com/tektoncd/plumbing/pull/121. The only difference is the removal of the replace line in go.mod. Otherwise this should be good to go.
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:

[x] Includes tests (if functionality changed/added)
[x] Includes docs (if user facing)
[x] Commit messages follow commit message best practices

See the contribution guide for more details.
Double check this list of stuff that's easy to miss:

If you are adding a new binary/image to the cmd dir, please update
the release Task to build and release this image.

Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes
Update project to use Go modules.

/hold for https://github.com/tektoncd/plumbing/pull/121

/hold
https://github.com/tektoncd/plumbing/pull/121

Looks really good. The only "question"/"worry" I've got is on the removal of the vendor folder (at least for now). On cli we did keep the vendor folder for several reason (that may need to be re-discussed :stuck_out_tongue:)

Allows to do go build -mod=vendor … to build tkn without needing anything more that a git clone
On the same note as above, if for some reason I'm off the network or have a slow network, or github is messed-up (or my GOPROXY), I can still build it
Whenever we had problems with go mod (from 1.12 to 1.13), contributor could still work and hack on the cli as long as they didn't change dependencies
Allows "older" version to build (this is a bit weird as.. depending on what we are using from the standard library it might not be true anymore but..)
and a totally stupid reason : it makes the diff smaller :joy_cat:

All that said, I am fine with whatever we choose, but we should probably do the same on all project then.
/cc @chmouel @bobcatfish @ImJasonH @dibyom
PS: I am a bit biased when talking about go modules :stuck_out_tongue_closed_eyes:

@vdemeester

On the same note as above, if for some reason I'm off the network or have a slow network, or github is messed-up (or my GOPROXY), I can still build it
Do you need to be online for every build, or just the first one?

@vdemeester

On the same note as above, if for some reason I'm off the network or have a slow network, or github is messed-up (or my GOPROXY), I can still build it

Do you need to be online for every go build, or just the first one?

Just the first. Modules are cached locally at $GOPATH/pkg/mod. One thing to note though is that modules are fetched lazily, so if you do a clone then disconnect you may not have all dependencies locally. You would need to do something like go build ./... or go get ./... to have the go tool resolve and cache the dependencies.

I have a slight preference for keeping vendor/ as well for the reasons Vincent outlined. They also must be included in the released images, so having them all the time makes that easier.

/test pull-tekton-pipeline-build-tests

I have a slight preference for keeping vendor/ as well for the reasons Vincent outlined. They also must be included in the released images, so having them all the time makes that easier.

Is this for reciprocal licenses? If so, go-license takes care of this and puts code into third_party. We should verify even in the vendorless case this folder is exported properly though.

My preference is to omit the vendor directory.

it makes PR sizes more representative of the changes being made (e.g. no XXL PRs because a new dep was added)
it prevents future repo size creep from transitive dependencies. vendor is ~92% (53/58MB) of the on disk size of the pipelines repository. Although we can't remove this from the history, we can curb additional growth (as a somewhat exaggerated comparision, kubernetes/kubernetes vendor is 110MB).
you don't need to remember to pass in / export -mod=vendor to use the vendor directory.

The most compelling argument to keep vendor for me is compatibility with older Go versions, but vendor support exists since 1.11 (released 2018/08). I'm not sure about pipelines, but triggers requires Go >= 1.13, so I don't think we really need to worry about this too much.

Is this for reciprocal licenses? If so, go-license takes care of this and puts code into third_party. We should verify even in the vendorless case this folder is exported properly though.

Some dependencies (hashicorp/lru) require us to include the source code, not just the licenses.

Is this for reciprocal licenses? If so, go-license takes care of this and puts code into third_party. We should verify even in the vendorless case this folder is exported properly though.

Some dependencies (hashicorp/lru) require us to include the source code, not just the licenses.

Yup! We're on the same page. =] go-licenses copies anything that is identified as reciprocal  to third_party/.

Paging @wlynch @ImJasonH @vdemeester have you spoken any further on this issue?  As Jason mentioned offline the other day now's a good time to get moving on this since the latest release has just gone out and we're not scrambling to get a new one ready.
Given that go-licenses seems to do what we want with source code and license files I see a couple options:

Go ahead with removing /vendor. If we start getting signal that we've broken something or someone we can reintroduce it.
Continue ahead with the vendor directory but now using go mod instead of dep.  Consider its complete removal if clearer consensus is reached.

Either way it'd be great to get on the blessed go module path.

Paging @wlynch @ImJasonH @vdemeester have you spoken any further on this issue? As Jason mentioned offline the other day now's a good time to get moving on this since the latest release has just gone out and we're not scrambling to get a new one ready.
Given that go-licenses seems to do what we want with source code and license files I see a couple options:

Go ahead with removing /vendor. If we start getting signal that we've broken something or someone we can reintroduce it.
Continue ahead with the vendor directory but now using go mod instead of dep.  Consider its complete removal if clearer consensus is reached.

Either way it'd be great to get on the blessed go module path.

I'd like to submit this before more version changes/updates happen, so I'm going to proceed with #2. Like you said, we can continue discussing keeping the vendor directory after we switch to modules.

I'd like to submit this before more version changes/updates happen, so I'm going to proceed with #2. Like you said, we can continue discussing keeping the vendor directory after we switch to modules.

Right, let's go for keeping the vendor for now.

#1699 will fix the build :angel:

#1699 will fix the build 👼

Yeah, we'll still need the vendor/plumbing at least until we start consuming those via Tekton tasks.


Customized Dumps are slow

We have a customized dumps function in order to serialize dataclasses.
And @paulomaced  observed how slow our current dumps can be when a lambda running time from 1.8 seconds to 0.5 just by changing dumps function
We do not know if this behavior is caused by pydantic_encoder, ident=4 or sorted=True or if dumps function just slow
We should test different parameters over dumps function and actually consider use orjson instead.

When replace our dumps function to use orjson (remember of serialize default for decimals)

Wasn't this fixed in #26?


Chat UI Refactor

User Story
As a developer, I would like a consistent UI so that functionality across pages share similar features and event handling.
Detailed Description
Refactor Chat UI using MUI components.

rewrote UI using MUI components, added scroll feature, fixed styling


Add the Card icon to the CardNumberElement

The icon is only displayed with the CardElement, but it would be nice to have it on the CardNumberElement (maybe by passing some prop to it)

Hi @githubdoramon! Thank you for the suggestion.
react-stripe-elements is a a react-friendly way to use Stripe Elements, so it is limited to the features that Stripe Elements provide.
I will record this as a feature request for Stripe Elements.

@cweiss-stripe, but he icon is already displayed in the CardElement, so isn't it already a stripe element?

The card icon is only a part of the CardElement and can currently not be used outside of it or inside the CardNumberElement.

https://jsfiddle.net/ywain/L96q8uj5/
from
https://stackoverflow.com/questions/42262887/enabling-brand-icon-in-cardnumber-type-element-in-stripe

@cweiss-stripe  has this been added to elements? The https://stripe.com/elements
page banner has it:

@yinghaochan it has not, sorry. We'll keep you posted if we decide to in the future!

@atty-stripe Is there any update on this?

@atty-stripe Is there any update on this?

@SabirAmeen sorry, no updates here. We have no current plans to add the icon to the cardNumber Element. This is mostly because we want the cardNumber Element to be as vanilla as possible, allowing users to customize it as they wish. The jsfiddle above is an example of how you can add your own icons.

Does this solution work for react-stripe-elements also?

Any updates on this ? +1

I completely agree with @chrismanderson.
If their marketing page and site banner/demo is going to show it working then there should be a way for it to work. I spent 3+ hours trying to figure this out and come to find out it is not possible even though it shows it.
I understand that the elements are vanilla, but it wouldn't be that hard to have a boolean setting for this.
Love Stripe, but this is very disappointing.

The all-in-one Card Element that Stripe seems to be proud of has major usability and display issues (i.e. it's very buggy across all of the Stripe demos).  cardNumber needs an option for an icon.  Since you don't want to change the existing "vanilla" Element, here's my recommendation:  A new "cardNumberWithIcon" Element.  In the same vein, I would also like to see a "cardCvcWithIcon" Element.
The marketing materials for Stripe Elements clearly shows a credit card icon in a cardNumber field.  That's misleading/false advertising and carries penalties as per the FTC:
https://www.ftc.gov/news-events/media-resources/truth-advertising
At the very least, Stripe has clearly broken FTC regulations.
In addition, by NOT implementing this into Elements, Stripe is significantly contributing to direct violations of Visa rules regarding online sales on sites that use Stripe Elements:
https://usa.visa.com/run-your-business/accept-visa-payments/posguidelines.html
Which says:

All physical merchant locations, online merchant locations and ATMs that accept Visa products for payment or cash disbursement must display the Visa POS Graphic.

In short, any website that does NOT display the Visa POS Graphic anywhere but uses Stripe payments via the cardNumber Element is in direct violation of Visa's rules regarding acceptance of Visa cards.  Most other card processors have similar rules regarding the display of their graphics.  Nowhere in the documentation is this mentioned, so there are probably a lot of websites in violation.  Visa, Mastercard, et al would be VERY interested in this thread to see Stripe's rather blasé response.
Finally, all the devs who find this thread expect the feature to be built into Elements since your marketing materials show the feature as existing alongside of cardNumber fields.  However, it simply does not exist, so each dev who runs into this issue has to go download either a font or a bunch of icons at different sizes, possibly committing licensing violations while doing so AND what they download are most likely outdated icons or will be outdated in a couple of years, and then write and debug HTML, CSS, and JS to show the icons at the appropriate times.  That is, make it themselves, which your marketing materials also clearly say that devs won't have to do!  Beyond violating Federal regulations and Terms of Service with various card companies and banks, there are a variety of sensible reasons to have the feature as well mentioned elsewhere in the thread.  Stripe's position is also in the wrong here as evidenced by the various downvotes against Stripe employee comments within this thread.  In addition, Stripe's last valuation was around $22.5 billion USD, so Stripe has plenty of resources to accommodate us.  Please make this a priority and just do it.  Thanks.

+1 - come on stripe, if the card element can handle it why can card number not?

Hi @cubiclesoft, this is a feature request that we’re aware of and tracking internally. This repository is for support for the react-stripe-elements project. For general Stripe.js and Elements support, please reach out to<EMAIL_ADDRESS>Thank you!


@prop syntax for custom SchemaType

Is there any way to specify that a property has type that comes from a mongoose custom SchemaType?

currently, there are no tests for it, so i assume it dosnt work, at least its not officially supported

@Ben305 this can be closed in favor of https://github.com/hasezoey/typegoose/issues/36


create autoblacken action

Codecov Report

Merging #1 (86b72e8) into main (37327e4) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #1   +/-   ##
=======================================
  Coverage   83.33%   83.33%
=======================================
  Files           1        1
  Lines           6        6
=======================================
  Hits            5        5
  Misses          1        1

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 37327e4...86b72e8. Read the comment docs.


Keep uploaded meta image URLs relative

In production the image() function in templates returns an absolute URL to the image's S3 location. In other environments it returns a relative URL. So prepending {{ request.scheme }}://{{ request.get_host() }} doesn't play nicely with production.
Checklist

[ ] PR has an informative and human-readable title
[ ] Changes are limited to a single goal (no scope creep)
[ ] Code can be automatically merged (no conflicts)
[ ] Code follows the standards laid out in the development playbook
[ ] Passes all existing automated tests
[ ] New functions include new tests
[ ] New functions are documented (with a description, list of inputs, and expected output)
[ ] Placeholder code is flagged
[ ] Visually tested in supported browsers and devices
[ ] Project documentation has been updated
[ ] Reviewers requested with the Assignee tool :arrow_right:

@contolini can you please review my changes in 7c816be? I use HttpRequest.build_absolute_uri to force use of an absolute URI for images. This works locally by generating http://localhost:8000 URLs for images, and should also work in production using S3 (see unit test that sort of checks this, I also verified locally).

@chosak crushes it once again


deleting bug

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '....'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS Version: [e.g. Windows 10 20H2 19042.804]
App version: [e.g. v1.0]

Additional context
Add any other context about the problem here. Does this problem occur again after restarting the app?
Log file
Please upload the log file here so that we can understand your issue better. You can access it from Settings->About->Open log location. You can also find this file by going to %localappdata%\Packages\49306atecsolution.FilesUWP_et10x9a9vyk8t\LocalState, you should see a file in this directory called debug.txt or/and debug_fulltrust.txt.

Could you explain where the issue lies, and provide a log file?

when im trying to delete something(big files or folder) app just closing

@iamhashimov What version of Files do you have?


RancherOS tasks 3/25/2015

Max Log Size support [MERGE]
Docker Daemon lifecycle support [MERGE]
SIGCHLD handling [MERGE]
Better restart policies [MERGE]

Max Log Size Support [PR]
Docker Daemon lifecycle [PR]
SIGCHLD handling - WIP
Better restart policies [PR]
Slave and shared mounts in Docker - WIP

Max Log size (PR submitted to Docker to be able to specify logs)
Docker Daemon Lifecycle (PR submitted)
SIGCHLD - still WIP
Better Restart Policies - PR submitted
Shared mount support - pushing aside
Slave mount support  - PR submitted to Docker
configure user via cloud-init
Work on DO support

Configure user via cloud-init [PR]
Added link local support
Using docker-machine to launch RancherOS on AWS.

created a PR in docker-machine to configure user to rancher user.
make sure it works for rest of the supported drivers in docker-machine.


feat: update access-keys.mdx

Provide better explanation of api-key scopes, and replaces clusters with projects as scopes are only available for projects, virtual clusters and namespaces - NOT clusters.
Supersedes: https://github.com/loft-sh/vcluster-docs/pull/275

@kmadel I couldn't push to your branch, but rebased off of your PR. Could you please check if it's ok and approve?


Fix dependencies of hklpy

Based on reports, one or more of the following are probably missing from our recipe. I haven't checked.
gsl libiconv pcre hkl

Check the extra stuff added to CSX

Noting here an in-person conversation with @tacaswell:
It's likely that our recipe for hkl (not hklpy) failed to properly list all its dependencies, and that this is the cause of the problem. Complicating matters, the hkl package cannot be built in our standard Docker because it needs particular system libs to be available. The binary that we distribute now was built manually by Tom on freyja. It will need to be manually rebuilt with a corrected recipe that properly declares all the dependencies.

Just to check, the hkl package is the same as the libhkl package in debian ?

Sorry, neither @tacaswell or I know the answer to that.

The hkl package is the same - but I don't recall if we had local modifications https://packages.qa.debian.org/h/hkl.html

I think it's taken care of by https://github.com/NSLS-II/lightsource2-recipes/pull/303 and https://github.com/NSLS-II/lightsource2-recipes/pull/310.


As a developer, I want the project to compile, so that I can do stuff with it.

Addressed by https://github.com/WSU-CEG-6110-4410/ADAD-Craft/pull/96


New package: LogDensityProblemsAD v1.0.0

Registering package: LogDensityProblemsAD
Repository: https://github.com/tpapp/LogDensityProblemsAD.jl
Created by: @tpapp
Version: v1.0.0
Commit: c2993f6594a47c90794460df235df1cf6bf450f0
Reviewed by: @tpapp
Reference: https://github.com/tpapp/LogDensityProblemsAD.jl/commit/c2993f6594a47c90794460df235df1cf6bf450f0#commitcomment-90710612
Description: AD backends for LogDensityProblems.jl.

The new package is code factored out from the old package, hence the name. Spelling out AD would make the name unwieldy, so I would like to get it registered under this one.

Do you need to retrigger the CI @tpapp now that @fredrikekre added the override tag?

No.

Is something holding this back still?

No.


CI updates

Self-ACK, this only alters the surrounding CI infra for aggregation and is necessary to fix breakage.


How to check the current cache size and delete them

How to set the cache size? Tons of images will be cached in the local storage, methods to check the current cache size and delete all cached files, or a prop to set the limit of cache size would be very helpful.

yeah this has been requested.. I have to look into this.


Normalizing an existing file URI breaks extension discovery

When calling findExtensions the packageConfig uri that is passed in is normalized here:
https://github.com/dart-lang/tools/blob/main/pkgs/extension_discovery/lib/extension_discovery.dart#L150
File.fromUri(packageConfig).absolute.uri;
This causes issues when packageConfig is already a file URI.
Example: when the URI "file:///Users/kenzieschmoll/develop/gallery/.dart_tool/package_config.json" is passed, the code above transforms this URI to "file:///Users/kenzieschmoll/develop/dart-sdk/sdk/file:///Users/kenzieschmoll/develop/gallery/.dart_tool/package_config.json", which then causes an error to be thrown indicating the package config file cannot be found.
This is breaking DevTools extension support. @jonasfj

In DevTools PR https://github.com/flutter/devtools/commit/89c7a4861fbd874c5af5c919a95a6e32af0fedcc, we started passing in File URIs to support windows users but this appears to have broken things for linux. CC @DanTup
Can we make extension_discovery more robust so that it can handle file URIs too?

The code for determining an absolute path seems odd that it doesn't take file uris into account: https://github.com/dart-lang/sdk/blob/66445534ea81db03a3c47831d0a830ff9c3f05f2/sdk/lib/io/file_system_entity.dart#L535-L544

Example: when the URI "file:///Users/kenzieschmoll/develop/gallery/.dart_tool/package_config.json" is passed, the code above transforms this URI to "file:///Users/kenzieschmoll/develop/dart-sdk/sdk/file:///Users/kenzieschmoll/develop/gallery/.dart_tool/package_config.json", which then causes an error to be thrown indicating the package config file cannot be found.

Do you have an exact code sample that reproduces this? I tried on macOS but couldn't reproduce. Given:
import 'dart:io';

void main() {
  final packageConfig = Uri.parse(
      'file:///Users/kenzieschmoll/develop/gallery/.dart_tool/package_config.json');
  print(File.fromUri(packageConfig).absolute.uri);
}

I see:
file:///Users/kenzieschmoll/develop/gallery/.dart_tool/package_config.json

From your comment is sounds like this is only a Linux issue, but I can't think of a reason why Linux and macOS wouldn't match.

The code for determining an absolute path seems odd that it doesn't take file uris into account: https://github.com/dart-lang/sdk/blob/66445534ea81db03a3c47831d0a830ff9c3f05f2/sdk/lib/io/file_system_entity.dart#L535-L544

Isn't this class only dealing with paths, not URIs?
Hmm, I'm slightly suspicious about this line here:
(packageConfig.hasScheme && !packageConfig.isScheme('file')

Why is it allowing empty schemes? Is the broken path here getting a URI without a scheme? If so, I think we should remove that hasScheme check, always throw if it's not isScheme('file') and fix the source of the URI.

To repro this, I am on flutter master and serving DevTools with devtools_tool server --build-mode=debug. Then running Flutter gallery and connecting to DevTools. For whatever reason File.fromUri(packageConfig).absolute.uri prefixes my file URI with file:///Users/kenzieschmoll/develop/dart-sdk/sdk/.
You are right that the file uri returned false for isScheme('file'). It seems strange that the Uri.file constructor does not automatically create a URI object with the 'file' scheme: https://github.com/dart-lang/sdk/blob/66445534ea81db03a3c47831d0a830ff9c3f05f2/sdk/lib/core/uri.dart#L1868

I pushed up https://github.com/flutter/devtools/pull/6961 as a temporary fix. Although I still don't understand why Uri.file doesn't work for Mac but does for Windows. @DanTup can you confirm that using Uri.file indeed behaves as expected for windows?
Either way, there seems to be something fishy going on with Uri.file not constructing a URI where uri.isScheme('file') is true by default, as well as with the funky file.absolute prefixing with the current directory.

Although I still don't understand why Uri.file doesn't work for Mac but does for Windows. @DanTup can you confirm that using Uri.file indeed behaves as expected for windows?

Do you have a code sample you can run in isolation that triggers this? I did some testing on dartpad, but the only way I can get a Uri (using Uri.file) without the scheme is if it's relative (it's not clear to me if this is a bug, or if file: URIs don't support relative paths):
  print(Uri.parse('/foo/bar.dart'));        //    /foo/bar.dart
  print(Uri.parse('/foo/bar.dart').scheme); //    (blank)
  print(Uri.file('/foo/bar.dart'));         //    file:///foo/bar.dart
  print(Uri.file('/foo/bar.dart').scheme);  //    file
  print(Uri.file('foo/bar.dart'));          //    foo/bar.dart
  print(Uri.file('foo/bar.dart').scheme);   //    (blank)

Ok, I reproduced this, and the real issue is that Future<void> serveAvailableExtensions(String? rootPath) is being called with a rootPath like file:///Users/danny/Dev/Google/flutter_gallery - which is a string URI and not a "path".
If we do Uri.file('file:///Users/danny/Dev/Google/flutter_gallery') then we (understandably) get something broken, and using Uri.parse() is somewhat offsetting that.
I think the correct fix is to fix the call to serveAvailableExtensions to pass a path, not a string that is a file URI (and with that, you'll likely need to revert your workaround), or we change the signature to take Uri rootUri and ensure it's always a file URI.


Changing the way we handle metadata.

@dermidgen This PR is a work in progress. Tests do not pass yet. First, I want you to take a look at it and see if you agree.
The goal here was to fetch all of the metadate (which can be large) and cache it locally for faster retrieval later.
I also added a few changes to normalize the object returned by the xml parser so it's a more natural fit.
I'll add inline note on the diff view.

Note that I have been working on this for two main reasons:

I need this data to be able to more easily build queries.
I want to add one or two methods to help users inspect the schema they are working with. Think of a nicely-formatted dump of relevant metadata members.

By the way, run it like so:
DEBUG=rets.js:rets,rets.js:simple USER=... PASSWORD=... node examples/simple.js

Coverage decreased (-8.2%) to 84.07% when pulling 22dee6971a8b965f34dfdb769b557744c3174ceb on lgomez:metadata-fetching-caching into 1d9085336560be58a49bbe07bc99625796eb6860 on retsr:master.

@dermidgen Check this out!
Pull this and run DEBUG=rets.js:simple* USER=**** PASSWORD=**** node examples/simple.js

hahaha


Can't install matplotlib in raspi zero

To run program run.py from repository fish-length-opencv, I need to install some library into raspi:

numpy & some lib-dev to support numpy
matplotlib

But, when install matplotlib, this packages took many hours process:
    ...(process)...
    Building wheels for collected packages: kiwisolver
    Building wheel for kiwisolver (pyproject.toml) ... /

Use sudo apt-get install instead of pip install. There are some packages that not supported using pip anymore.
So, this will solve it:
sudo apt-get install python3-matplotlib

For modules: imutils I can use pip as normal as usual:
pip install imutils


Feature request: GetLatestTreeState

Quick summary:
GetLatestTreeState is to GetTreeState as GetLatestBlock is to GetBlock
Feature Request:
As a wallet dev, I'd like to have a single call that gives me the latest sapling tree so that I can stick it in the wallet right before a release in order to make new wallets creation as fast as possible.
implementation notes:

this would simply get the latest block height and then pass that to the existing method for returning the tree state

Checkpoints can now be trivially created with a curl!
grpcurl -d '{"height":1120000}' shielded.nighthawkwallet.com:9067 cash.z.wallet.sdk.rpc.CompactTxStreamer/GetTreeState


NPM Install results in ENOENT with Dependencies LTX

https://github.com/swissmanu/harmonyhubjs-client/blob/f6e165eb5b560ea53dd40230bfb6284627a51b69/package.json#L30
npm WARN deprecated<EMAIL_ADDRESS>use @xmpp/xml package https://www.npmjs.com/package/@xmpp/xml
npm ERR! not a package /tmp/npm-17423-xgU6Dk0q/github.com/swissmanu/ltx.git
info trying registry request attempt 1 at 06:32:31
http GET https://registry.npmjs.org/ms
http 304 https://registry.npmjs.org/ms
npm ERR! Error: ENOENT, open '/tmp/npm-17423-xgU6Dk0q/github.com/swissmanu/ltx.git-unpack/package.json'
I think it may be malformed.

is this still a problem?


add http-observatory tests

Add a locally (docker) deployed http-observatory test.
It requires a minimum score of 65, and also prints the test results to
stdout.
Helps with #473.
Will fail on travis for two reasons:

#505 - buildbot does not run automatically on travis right now
#511 - the security headers were not merged yet, so our score is 0

The code is not so elegant, running external code from within Python, but it works.

This change is

Thanks for the pull request, and welcome! The Servo team is excited to review your changes, and you should hear from @aneeshusa (or someone else) soon.

I'm OK with relying on the public Mozilla API instance instead of running our own in CI. I would much prefer to avoid Docker, and it is optional for the cli client, so please rework this to avoid the docker and docker-compose dependencies.
I believe that Travis uses a single mega-image for Trusty builds (which we are using), which already includes Node (for the cli client), although I might be wrong. No need to add Node to the Vagrant setup for now, since running the test suite in Vagrant already requires some extra undocumented steps.

Hi @aneeshusa,
The trouble with using the public API, is that it only checks public urls. That is the only reason I went down this much more complicated path of implementing our own CI.
So if we want to avoid docker and use the public api we can either:

Run the tests targeting the already deployed server. Quite weird because there is no connection between changing the code and the test results.
Run a publicly accessible staging server. Even more complicated than the docker solution, unsafe (the server runs publicly even if the tests failed).

Have I missed anything?
BTW, docker is also available on travis.

@jarondl That makes sense, I didn't think about that at 3am when making my last comment :)
I appreciate all the work you've done on this PR, but I'm still unconvinced that we need Docker running Postgres, Redis and Celery all to scan one website in CI; we don't need to save results or handle backpressure, etc.
Since this test isn't critical to saltfs functionality (aka builds getting run and merged), and we can always use the website to check our deployed site, I would rather not have this test at all than include all of that complexity (especially considering the fact that we can add simple checks for e.g. headers ourselves as in your other PR).
I also see you've asked them to start building official Docker images, but in the meantime I am reluctant to use a community image (even one you built!). I would want to either a) wait for an official image or b) have a script in saltfs to build + store one; more importantly I would want to pin the image via digest in all cases to avoid unnecessary surprises, which is then another thing to update, etc.
I'm not sure about the http-observatory internals, but assuming it's well architected I'm hoping there is a (even if unofficial) Python API we can use to grade a single site directly, without hooking into Postgres etc. If you are willing to figure out if/how that can be done, I would be much more amenable to integrating the observatory into our CI that way. (I can also likely poke around a bit.)

Hi @aneeshusa, with some tweaks and fixes ( mozilla/http-observatory#156 ) we could run a Python only scanner in about three lines of code. (Although with an unofficial API - maybe I could push something upstream..)
However, the observatory does require many Python packages we don't have. Should we put it in a separate virtualenv?

@jarondl Thanks for going above and beyond, pushing improvements to the observatory upstream :) Running a Python only scanner, even if via an unofficial API, would be great.
I'm OK with however many Python dependencies are needed, since these only need to be installed during testing; just drop them into the requirements.txt file at the top of the repo. Travis will install those automatically for our builds marked as Python builds, which includes servo-master1.
Just make sure to pin versions to prevent surprises, especially since we're using an unofficial API.

One note about integration: the tests already run under a Python3 interpreter, so you should be able to import the observatory modules and call functions directly from the test code, without needing a separate script/virtualenv and forking a separate Python process to run it.

I filed https://github.com/mozilla/http-observatory/issues/157 about an officially supported Python API, let's see what they say.

The unofficial local API is now official.  There is both a function you can call as well as a simple CLI that outputs JSON similar to what the API would output.  Hopefully that helps!


Restore inrefaces on restart in case of external VPP

Description
When we create VPP on the forwarder pod we assume that forwarder death means VPP death. But it is not right for the external VPP socket (e.g. Calico-VPP case). If forwarder restarts it can leave network interfaces there.
In this issue we need to prepare possible solutions.

Possible solution [DRAFT]
Use restoreInterface and expireInterface

Improve tag chain element to store not only connID but nsm prefix, client or server identification and expiration time. For example it can looks like:
nsm-c-1644245337-6434d7fe-a03c-40fe-8a38-321e5b7967c4, where

nsm - NSM prefix,
c or (s) - means client (or server),
1644245337 - expiration time in sec,
6434d7fe-a03c-40fe-8a38-321e5b7967c4 - connection ID
After each refresh we need to update the expiration time of the corresponding interfaces.

On the forwarder startup we need to Dump nsm interfaces and store them to the list of:

type interfaceInfo struct {
	clientIfIndex uint32
	serverIfIndex uint32
	connID string
	expirationTime uint32
}

Implement restoreInterface chain element
It receives a list of interfaceInfo on creation and restore the connection metadata in case of healing Request (or refresh)

Implement expireInterface chain element.
It will monitor the interfaces for their timely removal. It also receives a list of interfaceInfo on creation to start monitoring the old interfaces.
When time runs out it deletes clientInterface, serverInterface and all possible cross-connects

@glazychev-art Can we go with something more simple?
Basically, we need to do this:

Forwarder starts -> dump vpp interfaces and remember all tagged interfaces.
Start async delayed jobs for each dumped interface that will simply call Close via begin chain element. Delay time can be equal to maxtTokenLifeTime
For each refresh request from the client cancel the jobs from step2.

I guess tag can be: ${forwawrderName}-${connectionId}. It will allow using multi-forwarder instances for the node.

I partly agree.
Probably we can use tag like this:  ${forwarderName}-${connectionId}.
But what if forwarder restarted and ${forwarderName} was changed?
Concerning step 2:
We have no information about previous connections after Forwarder restart in begin:
https://github.com/networkservicemesh/sdk/blob/main/pkg/networkservice/common/begin/server.go#L87
And we have no metadata to delete something on Close.
For example, let's take a look at tap mechanism: https://github.com/networkservicemesh/sdk-vpp/blob/main/pkg/networkservice/mechanisms/kernel/kerneltap/common.go#L145-L146
maxtTokenLifeTime is expired:

After dumping, we don't know what mechanism was used.
We don't have swIfIndex in ifindex metadata. We need to fill all metadata somehow before the Close call.

The basic idea of the https://github.com/networkservicemesh/sdk-vpp/issues/512#issuecomment-1044531011 is:

Forwarder starts -> dump vpp interfaces and remember all tagged interfaces.
Start async delayed jobs for each tagged interface that will just remove interfaces via vpp-api, regardless of mechanisms or metadata after expiration time (e.g. maxtTokenLifeTime) (I think we can also remove L2xc or L3xc)
For each refresh request from the client cancel the jobs from step2 and fill metadata.

Additional thoughts.
We need to remember, that:

The forwarder can be restarted and its name can be saved.
The forwarder can be restarted and its name can be changed.
We can have many forwarders on the same node.

So, I think we need a more complex tag.
Like this: nsm-${client|server_identifier}-${refresh_identifier}-${forwarderName}-${connectionId}
Why do we need 'nsm-'?
If forwarder restarted and its name was changed  - this prefix is a reliable way to find nsm-interfaces.
Why do we need '${client|server_identifier}-'?
If we want to restore the previous connection we need to distinguish client and server interfaces to store their swIfIndexes in ifindex metadata.
Why do we need '${forwarderName}'?
We need to figure out - does this interface belong to our forwarder or not?
Why do we need '${connectionId}'?
We need to know the connection this interface belongs to
Why do we need '${refresh_identifier}'?
If we know, that this interface doesn't belong to our forwarder - we can keep track it until it expires. Then we can check, is '${refresh_identifier}' was changed? If yes - that means this interface is used by other forwarder (identifier was updated on refresh) and we don't need to delete it.
This identifier can be a simple counter.
Another question arises - the tag length is limited to 64 characters - https://github.com/FDio/vpp/blob/master/src/vnet/interface.api#L363

We discussed another solution internally.
Probably we need to manage only the interfaces created by this forwarder or the previous one (i.e. its name was saved after the restart)
In this case it is enough to use the tag like: ${forwarderName}-${client|server_identifier}-${connectionId}.
In other cases:

If it was grace deletion - we can try to call Close for all of the connections before closing the application. We can get connections, for example, using monitor.
If it was force deletion - we have no guarantee that interfaces will be removed. And the next forwarders will not be responsible for the previous.

@glazychev-art
We've internally discussed this problem with @edwarnicke
Discussion results:
We're seeing two basic cases:

Forwarder restart
Forwarder delete(or upgrade)

Case 1, currently can be considered with a tag-based recovery strategy as we discussed in the PR meeting.
Case 2, currently is blocked. We need to verify that folks are using the k8s deployments upgrade feature. If so we can consider a solution with clearing resources on the application stops.

@denis-tingaikin  @edwarnicke
So, I think now it will look like this:
Tag: ${forwarderName}-${client|server_identifier}-${connID}
We have 2 main steps:
Step 1
Forwarder starts -> dump vpp interfaces, parse and store to map[connID]*ConnectionInterfaces all tagged interfaces.
type DeleteFn func() error

type IfaceInfo struct {
	delete    DeleteFn
	value     interface{}
}

type ConnectionInterfaces struct {
	clientMeta map[string]*IfaceInfo
	serverMeta map[string]*IfaceInfo
}

ConnectionInterfaces.clientMeta/serverMeta map stores values for the metadata. For example, clientMeta["ifindex"].value = 1 will become to swIfIndex = 1 ifindex for the client metadata. We have several such metadatas (links, peers...)
We can determine which particular interface is being used by InterfaceDevType ("memif", "VXLAN" and so on...). So we can choose the correct delete function (e.g. "memif" - > DeleteFn).
So, after that step, we have parsed interfaces with the corresponding delete functions.
Step 2
Add restore chain element.

NewServer receives dumped map[connID]*ConnectionInterfaces. It also runs a goroutine for each connID to delete vpp-interfaces  if they are no longer in use (call DeleteFns). Delay can be equal to maxtTokenLifeTime.
If we get a Request or Close with connID that we already have in the our map - stop goroutine and restore metadata for this connection.

@glazychev-art Didn't we discuss adding an expire time to the tag in VPP so we could simply time things out?

@edwarnicke
Yes, but:

Tag will be longer (it is limited - https://github.com/FDio/vpp/blob/master/src/vnet/interface.api#L363)
I think it's much easier if we always use maxtTokenLifeTime as expiration time. I don't think this will be a problem...

@glazychev-art I think you are correct, using maxTokenLifeTime should work, it will eventually clean up the connections if they are not renewed.

@glazychev-art Might it be possible to solve this in a more localized fashion.
Right now, understanding of how to handle particular interfaces is 'localized' in a particular mechanism chain element.
What you are suggesting in step 1 would require having a second place that understand all of the mechanisms.
Might it perhaps not be simpler to have each mechanism chain element dump interfaces, keep a map[string][*interfaces.SwInterfaceDetails].  When the mechanism element gets a a connection request, for which it cannot find a swIfIndex in the context, it can simply look in the map for an interface for that connId, and if it finds the connId, delete the entry from the Map, and carry on with that swIfIndex as if it had created it (presuming the interface is of the correct type).
This localizes the issue to a particular mechanism, and so we don't 'smear' localized knowledge into the global sphere.
maxExpireTime after launch, you can just delete anything remaining in the Map.
Thoughts?

One other question... have you given thought to how this would intersect with VNI allocation?

@edwarnicke
Very good solution! But in this case, we are missing one of the most important parts - how do we remove expired interfaces from the VPP after maxExpireTime?
VNI... It's good that you pointed it out. Now it is stored in the local map.

So, VNI. At first glance, nothing bad will happen. Because:

If Client VxLAN side was failed - vni.Client doesn't work with the metadata at all - https://github.com/networkservicemesh/sdk/blob/main/pkg/networkservice/common/mechanisms/vxlan/vni/client.go#L56-L71
If Server VxLAN side was failed:
Case A: We receive the Request from the old client that we want to restore - vni.Server takes VNI from the mechanism - https://github.com/networkservicemesh/sdk/blob/main/pkg/networkservice/common/mechanisms/vxlan/vni/server.go#L78-L81
Case B: We receive the Request from the new client, but we have a VxLAN tunnel, that is not restored yet  (we didn't receive the Request from the "old" Client)  and the generated VNI matched the existing one - I think we will fail creating a new VxLAN tunnel, retry will happen and we will try again with a new random VNI.

We have also the problem with wireguard - we can't get the wireguard peer index using dump - https://github.com/FDio/vpp/blob/master/src/plugins/wireguard/wireguard.api#L98-L109
We have a logic based on the peer index - for example HERE and HERE

So, for cases where the forwarder has its previous name after a restart and we use an interface dump, we have the following problems:

VxLAN VNI - https://github.com/networkservicemesh/sdk-vpp/issues/512#issuecomment-1057669840
Wireguard peer dump - https://github.com/networkservicemesh/sdk-vpp/issues/512#issuecomment-1059143323

But we know that when users update the forwarder, the pod restarts without saving the name.
We have 2 options for this case:

Add cleanup chain element. It will store the delete functions in the metadata. As soon as the chain context.Done, these functions will be called.
Disadvantage: We need to add the delete function into each element of interest to us (for example, into a mechanisms). It looks like:

func create(...) {
....
cleanup.Store(ctx, isClient, "tap", func() error {
	_, err := tapv2.NewServiceClient(vppConn).TapDeleteV2(context.Background(), &tapv2.TapDeleteV2{
		SwIfIndex: rsp.SwIfIndex,
	})
	return err
})
...
}

Call Close(). Perhaps we should consider calling Close() as soon as the chain context.Done. For example, call it via begin, if possible.
Possible problem: since the chain context is already Done at the time of the Close call - there may be problems

@edwarnicke @denis-tingaikin
I've prepared the draft PR with an idea of how restoring can be implemented - https://github.com/networkservicemesh/sdk-vpp/pull/542
There, each element is only responsible for dumping its interfaces.
Could you have a look?


[ENHANCEMENT] support for gpu A40

How to use flux in gpu nodes with A40, as the current package only support for A100, A800 and H100? By the way, the intra-node A40 is connected by PCIe4.0.

You would need to manually add Sm86_{} in gemm_v2_ag_kernel.hpp, gemm_v2_reduce_scatter.hpp and gemm_v2_comm_none.hpp at where currently is Sm80{}. Note that the no-nvlink support is not fully open-sourced (see #32) and the performance in certain cases might be poor.

Please check https://github.com/bytedance/flux/issues/32.


Time Limit for active but idle Remote Desktop Services sessions does not support "4 hours"

If you are configuring the "Time limit for active but idle Remote Desktop Services sessions" policy through the MMC snap-in, "4 hours" is not an option in the drop-down. The closest options are "3 hours" and "6 hours".

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: cdad1b23-8c75-cd08-41cc-6313fc7016bd
Version Independent ID: f7979a0f-a1be-100f-33b5-01627c45f783
Content: Prepare and customize a master VHD image - Azure
Content Source: articles/virtual-desktop/set-up-customize-master-image.md
Service: virtual-desktop
GitHub Login: @Heidilohr
Microsoft Alias: helohr

@Karishma-Tiwari-MSFT Thanks for reporting this. We are looking into this and will provide an update accordingly.

@GuyPaddock I have assigned the issue to the content author to investigate further and update the document as appropriate.

@GuyPaddock : Thanks for the suggestion, and we updated the recommendation to 3 hours.

#please-close


Allow buying Land at arbitrary location out-of-order

With pre-minted tokens, it's not an issue.
With enumerable countable tokenIds starting from 0 then the next tokenId implies the coordinates via (id / 32, id % 32).
To preserve that relationship then tokenIds must be minted out-of-order.

Instead of using enumerable: have Land.mint(tokenId) function for arbitrary but not-minted tokenId from 0->1023. Use default _mint to set owner, etc. Minting should also choose random property of the land (akin to Plant DNA) via Chainlink VRF or alternatively blockhash or even difficulty.

We should then provide a way to efficiently query which locations of the map "exist" (minted).
We just need to return 1024 bits where each bit position is a tokenId boolean with value 1 if minted and 0 if not. Thus return an array of 4 uint256.


add some ut

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?

None

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

None

/retest

/retest-required


Fix int width for the LLP64 data model

Integers are 4 bytes wide on LLP64 platforms.
Sources:

https://en.wikipedia.org/wiki/64-bit_computing
https://en.cppreference.com/w/cpp/language/types

Thanks ! This means I may need to add more CI target

It may be a good idea, though I'm not really sure how easy it would be to add Windows CI targets on Github :thinking:

Well, we have 2 msvc runners. I may have badly configured them then.


Feature-Included makefile,golangcilint and actions

Included a makefile for npm feeds.
Included golangcilint for linting, and it is based on k8s sigs security profiles operator.
Included an action to check for the validity.

@jordan-wright I know you are working on refactoring the feeds packages. But this should help, I think.


remove stdlib dependency

cassowary.lua currently depends on a very old version of stdlib that is probably no longer supported (and is quite big as well). Newer versions of stdlib don't work at all due to various redesigns in stdlib.
This PR removes all stdlib dependencies by implementing Object, Set, merge and clone such that cassowary.lua is small and completely self-contained. This actually simplifies some of the existing _init code.
Tested under Lua 5.3 and LuaJIT.
All tests work (tested with Lua 5.3):
$ busted cassowary.lua/tests/
●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●
73 successes / 0 failures / 0 errors / 0 pending : 0.091388 seconds

There is a License issue : std is release under a different LICENSE than cassowary.lua.
You should copy some std files outside of cassowary.lua/cassowary.lua module.
If you need only one cassowary.lua file without std dependency, you should built it at a second step.
if is not too hard to inject the std modules in package.loaded.
Regards,

Maybe I should explain some more why this makes sense to me. Apart from the current cassowary.lua not working with any recent stdlib, which is downright frustrating for anyone trying to use this, I find the size a problem in certain use cases, as cassowary only uses a super tiny part of stdlib. For local installations, this is not an issue at all. But if you need to go for small build sizes and ship your lua code via the Web, e.g. via Emscripten (e.g. https://github.com/TannerRogalsky/love.js/), then having a big lib dependency that basically does nothing but provide an Object wrapper, is not great. I'm using cassowary as part of a love2d project and most people from that world won't use luarocks or the like. In many cases, even having one additional lib file is considered bloat in that world. Now, as cassowary has no inherent dependency on stdlib, I really think that a self-contained cassowary would make many people quite happy.

Thanks so much for this patch. I think removing std and having a self-contained cassowary is a great idea. I wrote cassowary when I was fairly new to the Lua ecosystem and thought that stdlib (1) was the Lua standard library and (2) had a fairly mature attitude towards API compatibility, but neither of these is true. I'll review the PR soon but am busy with a house move right now.

Man, I'm sorry. I totally forgot all about this patch. It was a great idea, but we've gone in the direction of replacing std with penlight. I'm sort of wary of reimplementing core stuff like object inheritance from scratch, so I'm a bit happier with the penlight solution, but I'm sorry you put work into this and I completely dropped the ball.

@simoncozens Hey, no problem, penlight is a good choice for sure.


Resolution for output images

Marcus, Thanks for sharing your nice augmentation tool. I really like it.
I am wondering how to keep output images to be the same resolution as input images after finishing augmentation. I do see that there is a loss of resolution for augmented images. Please let me know where I could make a change for the code in order to keep the same resolutions. Thank you for your advice!
Best regards,
Peter

Hi Peter,
I assume you mean the quality of the images rather than the dimensions of the images? In that case, saving as PNG may help, but each operation is going to introduce some kinds of artefacts due to resampling and so on.
Right now, users do not have the ability to change the resampling method (most operations default to bicubic) but I will add the ability to specify this in a future version, which I plan to release soon.
Of course you can add a resize operation as the final operation to a pipeline using the resize(probability, width, height) method with probability set to 1, if you do mean the dimensions of the images.


New Course In HIndi Added

What does this PR do?
In this PR  I,have added a new course ,Everything in hindi.
For resources
Added New Course In HIndi From India's One of the biggest coding channel.
Why is this valuable (or not)?
It is valuable because This  course is made from India's one of the best teacher .A This Course is totally beginner friendly
How do we know it's really free?
All the liks given in this course are of youtube video , so it is free
For book lists, is it a book? For course lists, is it a course? etc.
It is a course
Checklist:

[✅ ] Read our contributing guidelines.
[✅ ] Search for duplicates.
[✅ ] Include author(s) and platform where appropriate.
[✅ ] Put lists in alphabetical order, correct spacing.
[✅ ] Add needed indications (PDF, access notes, under construction).
[✅ ] Used an informative name for this pull request.

Follow-up

Check the status of GitHub Actions and resolve any reported warnings!

Please Review My PR


sudo-less option

In most cases, we only need to set-up the hosts file once. Asking for sudo again is annoying.
It should be possible to run kubefwd without sudo, e.g.`
sudo kubefwd hosts ;# set-up hosts file
kubefwd services

kubefwd needs to ability to bind to low port numbers as well. The only way to avoid using sudo is to run it as root or set up a user with advanced permissions (depends on your operating system). You can also set sudo only to only require a password the first time it is run within a time period.

Hi
sorry to pick this up again but I think a rootless option would make sense for a lot of use cases (e.g. restricted environments) Since you already provide the option to map ports it is easy to map them into rootless compliant port range.
Would you mind to think about this option again? You could fail with the sudo-error message in case somebody wants to map a non-bindable port.
Best regards

This would also require root-less permissions to /etc/hosts, which sounds exceptionally dangerous.

I agree. Another solution would be to mimik a dns server and the admin would add this to /etc/resolv.conf. In that case you still have control about the order of dns query and can run rootless. What do you think?


RFP - torrent-file-editor

Qt based GUI tool designed to create and edit .torrent files.

Home page: https://sourceforge.net/projects/torrent-file-editor/
Source: https://github.com/drizt/torrent-file-editor
Downloads: https://sourceforge.net/projects/torrent-file-editor/files/v0.3.10/

Status: Review
https://chocolatey.org/packages/torrent-file-editor

@chtof Thank you! Two nitpick:

The icon broke.
The “license” links to SourceForge page.

@FranklinYu

icon uploaded.
There is no license to download and I have only find license information on the SourceForge page ("GNU General Public License version 3.0 (GPLv3)").

There is license on GitHub.

@FranklinYu Corrected, thank you!

Status: Published
https://chocolatey.org/packages/torrent-file-editor
Can be closed.


ServicePrincipalCredentials outdated, should use ClientSecretCredential instead

Current tutorial would hit error:
AttributeError: 'ServicePrincipalCredentials' object has no attribute 'get_token'
Should update the tutorial using ClientSecretCredential
Thanks
[Enter feedback here]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: aeb96284-14f1-2118-09a2-7e9eea175cc7
Version Independent ID: d95ba2d5-a26c-d3d3-9ffc-4401603821a9
Content: Azure HDInsight SDK for Python
Content Source: docs-ref-services/latest/hdinsight.md
Service: hdinsight
GitHub Login: @tylerfox
Microsoft Alias: tyfox

@hwang-kinaxis , thanks for your feedback.
adding @msyyc to take a look on the doc issue.

@msyyc @yunhaoling Thanks for help. Do you have any progress? What is the python sdk version? I can not find the sdk version from theID: aeb96284-14f1-2118-09a2-7e9eea175cc7 Version Independent ID: d95ba2d5-a26c-d3d3-9ffc-4401603821a9?

It seems that it is the common issue not related with service details

@hwang-kinaxis  what is your python sdk version? And could you please share the tutorial  you are using?


feat: Add GraphQL query context based tracing

opentelemetry-instrumentation-graphql provides a GraphQLTracer (source) based on GraphQL::Tracing::PlatformTracing (source). This includes several schema level configuration options that can enable/disable specific parts of tracing.
The current options are global, but we could benefit from also having per request configuration. For example, a HTTP header may request verbose traces be recorded, ideally enabling enable_platform_field for only this request’s GraphQL execution. This way a client can be permitted to opt into tracing, without having to enable it for all requests.
To make this possible, the GraphQL execution context seemed like an ideal place to have this request specific configuration. Access to context is now possible as of graphql-ruby 1.13.13 and 2.0.9 (see changelog, added in #4077), meaning we have this option going forward, but potentially need to remain backwards compatible.
In cached_platform_key, the newer versions of graphql-ruby have both context and trace_phase, so we can determine which setting to check and which of platform_field_key, platform_authorized_key, platform_resolve_type_key would be called on a cache miss.
If we were to release a new version of opentelemetry-instrumentation-graphql, how should we handle checking the version of graphql-ruby, either being backwards compatible or having a minimum version?
The CI failures have come up since cached_patform_key now expects 3 arguments (trace_phase being the new one) in newer versions of graphql-ruby.
cc @ravangen

Thanks so much for the contribution @toneymathews! I need to familiarize myself with the changes in graphql-ruby and how cached_platform_key fits into the overall upstream tracing strategy before commenting on that.
On the topic of version compatibility: generally speaking, each instrumentation gem's Instrumentation class, which subclasses Instrumentation::Base, calls a compatible block to determine if the version of the gem being instrumented is compatible with our instrumentation library.  I think that our current GraphQL Instrumentation class does not call this block, but it probably should.
If we imagine a world where there is a compatible block in the our GraphQL Instrumentation class, then most likely we'd need to decide if the feature being proposed here is worth breaking compatibility with older versions.
A couple alternatives to that:

We could dynamically select different code paths depending on which version of the gem is installed (that sounds like a maintenance headache)
There might be some clever way to work around the problem you're facing in this specific instance, which means we might not have to solve the general problem.

The other @open-telemetry/ruby-contrib-maintainers may have some thoughts on a more holistic strategy for managing compatibility, here.

Thanks for adding to Appraisals @toneymathews! Will take a look.

I've assigned this to myself, I'll work towards giving this a proper thorough review this week. It has a few implications, and unspecified behaviour so we need to be really detailed here.

Thank you for taking the time to review the suggestion and give it some thought.
GraphQL is not necessarily invoked through an HTTP request, although is the most common scenario. GraphQL being HTTP agnostic means that something needs to tell GraphQLTracer how to read the specific execution's configuration.
Practically speaking, I am unclear on an alternative to how the current request object or configuration is proposed to be passed down into the GraphQLTracer. Note that context was not usable prior to graphql-ruby < 1.13.13 and >= 2 and < 2.0.9.
HTTP baggage header is an option that can inform what is set in the GraphQL execution context. The current proposed approach is unopinionated, leaving it to the application code to know how to set these optional override settings.

It would allow us as users to add a baggage header that says something like "baggage: ServiceC=enable_platform_field;" which could signal which application we want to enable high the verbosity request tracing.

A frontend client may not know the "service name" to put into a baggage header, and instead elect to just say "debug my request" through a query argument or request header for example. Some app logic could still transform such a flag into a baggage header for propagation internally.
Regardless, these changes can work with distributed tracing. Configuration can still be propagated across service boundaries using whatever tooling exists today I imagine. GraphQL wouldn't be concerned with this propagation as it is not directly the mechanism calling other services, instead it would be other clients (which are likely instrumented).


Add support for INSERT OR REPLACE on SQLite

First piece of #196. SQLite has extremely simple semantics here. INSERT OR REPLACE will literally take what the new row would have been had the
insert succeeded, and will replace the existing row with it. For this to
be most useful, we'll probably want to make it easier to use non-literal
expressions in insert at some point in the future. We'll need to see
what other usage looks like.
This also lays the groundwork for supporting the other modifiers on
SQLite. I had originally planned on doing an API that looks more like
what PG will look like. However, since the semantics are so different,
we'll probably want to keep the APIs from stepping on each others toes.
Another alternative I had leaned towards was insert.or(replace).
However, as I started thinking about the compile fail tests that'd be
required there, and saw the implementation, I shied away from it. Since
there's a fixed set of 4 modifiers that we will support, I think one
function each is fine.

Review? @diesel-rs/core
/cc @llogiq

@sgrif Thanks for the ping and the fast implementation. I'm very impressed with what I see so far. In fact I'm so impressed, I may blog about it.

@llogiq :heart: !!! Let me know if there's anything else you're missing.

LGTM.

Cool! :+1:


Make working with promises of promises easier

Adds next_unwrap method to Promise. next_unwrap makes working
with types like Promise[Promise[Foo]] much easier to work with
compared to using next.
The idea for next_unwrap was my idea while working on a Pony client
for the GitHub REST API. The implementation itself was written by
Joe McIlvain.

This needs to be squashed once approved. I'll take care of that.
I have a GitHub REST API library that an early version of will be released after this is merged and I do a ponyc release.

Are we settled on the naming here? In most contexts I see a method like this is almost always named as flat_map or rarely and_then/bind, do we have a chance to lean into one of these namings? Would flat_then or then_flatten be more suitable to reduce context switching overhead between Pony and non-Pony?

I think Joe's next_unwrap is a good name in the context.
I think that flat_next is probably in the same ballpark as next_unwrap for "i might guess what this does" if you don't have the FP background.
Of the two that Jason mentioned, i find next_flatten to be preferable.
Of the existing and Jason's two names, I'm pretty apathetic. Any of the three is about the same to me.
@jemc you did the naming from my original "when", do you have a preference?
I have a library to release that is waiting on this, so i'd like to make any decision quickly.

I approve of using flat or flatten as a word instead of unwrap. It's definitely no worse than unwrap for describing what's going on. And since Jason sees it as better, I'm good with that. :+1:
So I'd be good with next_flat, next_flatten, flat_next, or flatten_next (only the 2nd and 3rd of which were actually suggested by Jason above).

@jasoncarr0 what do you think of flatten_next? I like it the most.

at the moment however i have renamed to next_flatten and I'm good with that as well. I'll leave next_flatten and flatten_next choice to @jasoncarr0.

I realized that my test case is totally bogus and I'm trying to figure out how to actually test this. Its non-trivial.

ok figured it out. god that test did NOTHING. dur.

correction, i figured some out.
i have other tests that are failing and... i can try out with real world stuff from my library that this started in and they work, so... arg.

@jemc we definitely missed a case.
There outer promise is always using RejectAlways which doesnt send down the chain to the inner.

I pushed some tests. 2 fail. One is the "outer reject doesn't call inner reject problem"
I'm checking the other failing test to make sure its not buggy.

Ok other failing test (so far):
    let start = Promise[String]
    let inter = start.flatten_next[String](
      _FlattenNextStartHelper~successful_fulfill(
        second_string, h, initial_string),
      _FlattenNextStartHelper~reject_fail_if_called(h)
    )
    inter.next[None](
      _FlattenNextInterHelper~error_fulfill(h, second_string),
      _FlattenNextInterHelper~reject_expected(h, expected_reject_string)
    )

so       _FlattenNextInterHelper~error_fulfill(h, second_string), run and it does error, but...
      _FlattenNextInterHelper~reject_expected(h, expected_reject_string) doesn't get run.

@jasoncarr0 @jemc what is the test case for the issue that Jason pointed out?

@jasoncarr0 can you review the new tests and tell me if you think anything is missing?

This test also fails:
class iso _TestFlattenNextStartFulfillErrors is UnitTest
  fun name(): String => "promises/Promise.flatten_next/start_fulfill_errors"
  fun apply(h: TestHelper) =>
    let initial_string = "foo"
    let expected_reject_string = "rejected"

    h.long_test(2_000_000_000)
    h.expect_action(initial_string)
    h.expect_action(expected_reject_string)

    let start = Promise[String]
    let inter = start.flatten_next[String](
      _FlattenNextStartHelper~error_fulfill(h, initial_string),
      _FlattenNextStartHelper~reject_fail_if_called(h)
    )
    inter.next[None](
      _FlattenNextInterHelper~fulfill_fail_if_called(h),
      _FlattenNextInterHelper~reject_expected(h, expected_reject_string)
    )

    start(initial_string)

The issue as can be seen with https://playground.ponylang.io/?gist=4b958c4198f8986b2b95d554b8476dcc is that an error in fulfill apparently shouldnt cause that same reject to occur only the ones later down the chain. That's an existing bug that we didn't replicate.

@jemc one of the bug fixes though means that we dont need rejected in the fulfill block (that makes sense) so it should be easier to set up the reject handler wrapper although i am struggling with it at the moment.

Ok I have all my tests passing.
@jasoncarr0 please review my tests and see what cases you think are missing and ill add.

@jasoncarr0 I believe this is ready to be squashed and merged. See my replies re: tests, those complete calls are correct as they are on _FlattenNextInterHelper not _FlattenNextStartHelper. If they were on _FlattenNextStartHelper, there would be a problem with complete being called early, but they aren't.

I did some renaming of things in the test and because this is fairly complicated, added english lanuage descriptions of what is and is not expected for each test.

I think this is ready for a squash and merge. Once approved, I'll do the squash so I can update the commit comment to match the changes this underwent since the PR was opened.


Adding V3 pool roles

closes #1086

I would only change the owners types to string instead of bytes. Not sure why the owner was bytes before. Rest looks good

I would only change the owners types to string instead of bytes. Not sure why the owner was bytes before. Rest looks good

it might be consistency problem, because all other addresses are bytes as well.

Ok. Lets leave it like this then and refactor another time 👍


Text definition of contributesTo is too narrow.

In English, the meaning of 'contributes to' is very broad.  So it would be sensible to say that a degree in computer science contributes to a person developing programming skills.  The text definition of contributesTo is:

“The parts of a system contribute to the goal/ function of the whole system”

If you say a degree in computer science contributes to a person developing programming skills, there are no parts of any system per se, so it does not align with the text definition of contributes to.
I’m saying that the definition of contributesTo is too narrowly focused on system-think, which is historical due to its origin in the network sub-gist.
PROPOSAL:

change the text definition to be more general
convert the current text definition into a skos:example

ALTERNATIVE:

instead of contributesTo use facilitates, which has similar meaning, but I think fits in more contexts.

I agree with broadening the definition of contributesTo. I think of examples as being more specific - individual cases - so I would just toss the current definition altogether.

This is subsumed by #534 but I'll leave it open so we make sure to take these points into consideration.

@uscholdm <skos:definition rdf:datatype="&xsd;string">Something that has a share in bringing about a result.</skos:definition>
<skos:example rdf:datatype="&xsd;string">Example1: The parts of a system contribute to the goal/ function of the whole system.  Example 2: Fructose contributes to obesity in some people.</skos:example>


Add function to search Dash.app

Plugin for searching Dash.app

Been using this since 2014, still :+1: for me :)

Added comment to the code. Seems the defaults may have changed name:
com.kapeli.dashdoc

com.kapeli.dashdoc is used by Dash 3 and Dash 4. com.kapeli.dash is used by Dash 2.

I've merged it (about time) even if there is a mismatch between versions. Open an issue or PR (preferably) about these changes. Not sure how to query for the version of an app in macOS. Also a README for the plugin would be nice.


[doc] Fix typos, mostly in Markdown files

Fixes #14805

I noticed this was failing the quality check, so I rebased on a new commit where I ran util/fix_trailing_whitespace.py.

lgtm.
btw, dumb question, did you actually read through all of these?? or is there some spell check tool we can apply to an entire repo or something?

No, I didn't read every file, but I did read the context for each change :)
Basically, I ran find . -name '*.md' and executed aspell check, which pops up a curses interface and walks you through possible misspellings. There's a lot of noise, so I ended up ignoring 80% of the suggestions. Not quite ready for automation. (I'm pretty sure I've seen a spelling-correction bot on the Chromium Gerrit instance before — I may take a peek at how that works.)

Thanks for the cleanup!


3 2 branch

Hello @benrabia,
Apart from the version and date changes, all these commits have already been forward ported to the master branch so we can close this! Thanks anyway!


Richardcho/add correlationid answeredby

Add correlationId to CallConnectionProperties
Add operationContext to AnswerCallOptions
Add answeredByIdentifier to CallConnectionProperties

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-communication-call-automation


Add source-code-folder-path parameter and add default values for other parameters

This pull request does a few different things:

Adds the source-code-folderpath parameter. This parameter allows us to specify what the subfolder is named that will get the generated source code files. I found that when we were specifying the output folder, we were including the lib folder in the path. Now that we're generating package.json, README.md, and LICENSE.txt, it isn't quite right to specify the path to the lib folder as the output path, because these three files actually go one level up from the lib folder. I chose to say that the package.json, README.md, and LICENSE.txt files will be placed at the output path, and then source code files will be placed within a subfolder that can optionally be specified by the source-code-folder-path parameter. If it is not specified, then it will default to lib.
Refactor CodeGeneratorJs and CodeGeneratorJsa. To do the first task, I had to make changes in both CodeGeneratorJs and CodeGeneratorJsa. I noticed that much of these two files is the same, to I extracted common functionality into methods within CodeGeneratorJs.
Adds default values to GeneratorSettingsJs. Package.json and LICENSE.txt files are now generated by default.

🤖 AutoRest automatic publish job 🤖
> will publish once PR gets merged

🤖 AutoRest automatic feature coverage report 🤖
feature set version 2.4.3
❌ General: 0%
no tests were run for this category
✔ Azure: 100%

🤖 AutoRest automatic feature coverage report 🤖
feature set version 2.4.3
❌ General: 0%
no tests were run for this category
✔ Azure: 100%

🤖 AutoRest automatic publish job 🤖
> will publish once PR gets merged

🤖 AutoRest automatic feature coverage report 🤖
feature set version 2.4.3
❌ General: 0%
no tests were run for this category
✔ Azure: 100%

🤖 AutoRest automatic feature coverage report 🤖
feature set version 2.4.3
❌ General: 0%
no tests were run for this category
✔ Azure: 100%

🤖 AutoRest automatic feature coverage report 🤖
feature set version 2.4.3
❌ General: 0%
no tests were run for this category
✔ Azure: 100%

🤖 AutoRest automatic publish job 🤖
> will publish once PR gets merged


feat(uat): add test cases for message expiry interval

Issue #, if available:
Add test cases to T102 for 'message expiry interval' feature
Description of changes:

Add steps to set and reset 'message expiry interval' in transmitted and expected received message
Add step to reset event storage and all MQTT v5.0 settings
Add test cases to test 'message expiry interval' feature of EMQX
Add messageExpiryInterval to EventFilter and implementation
Reoder steps code to be in the same order as in MQTT v5.0 spec to avoid mess
Update uat/README.md to use @SkipOnWindows

Why is this change necessary:
These test cases testing 'message expiry interval' MQTT v5.0 feature
How was this change tested:
Any additional information or context required to review the change:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Test failed: https://github.com/aws-greengrass/aws-greengrass-client-device-auth/actions/runs/5511482547/jobs/10047090364?pr=365#step:3:27309

We have failed test case with message expired interval until bug will be fixed in paho java client


Added slack notifications on_failure cases to the individual site pipelines.

Added slack notifications on_failure cases to the individual site pipelines.
Pre-Flight checklist

[ ] Screenshots and design review for any changes that affect layout or styling - N/A
[ ] Migrations

[ ] Migration is backwards-compatible with current production code - N/A

[ ] Testing

[X] Code is tested
[X] Changes have been manually tested

[ ] Settings

[ ] New settings are documented and present in app.json - N/A
[ ] New settings have reasonable development defaults, if applicable - N/A
[ ] Opened issue for DevOps regarding necessary configuration changes to deployed environments - N/A

What are the relevant tickets?
#1323
What's this PR do?
This will add slack notifications to #ocw-publish-notifications and #ocw-publish-notifications-rc channels when the pipeline fails. The notifications include a short description of the nature of the failure as well as a link directly to the job that failed. There are no notifications sent when the job is successful.
How should this be manually tested?
Will test in QA by creating the 'slack-url' key in vault and then working with someone in dev to repopulate the pipeline definitions.
Repeat the procedure to production.
Where should the reviewer start?
(Optional)
Any background context you want to provide?
(Optional)
Screenshots (if appropriate)
(Optional)
What GIF best describes this PR or how it makes you feel?
(Optional)

Can we name them #notifications-ocw-publish instead of #ocw-publish-notifications ?

Yes, I believe I can change the channel names.

Do we need 2 channels , one for RC and one for prod, or one would be enough ?

Well, I thought "No one actually wants to hear about failures for RC do they?" So I figured the easiest way to deal with that while still being able to test it is to make its own channel and when I'm done I can just turn off notifications / disable the webhook. I want to be able to test and have a uniform config between RC + Prod but I don't think there is desire to have RC generating notifications under normal circumstances. The easiest way to do that is to give it its own channel.


Fix #228, use custom documentation rules

This pull request builds the final URL like that:
${rule.url}#${rule.name}
I prefer to define the rule url independently from the rule name.
One might link to a page or an anchor that is named differently from the rule name.

@djtarazona Fixed this one


Is there an "archive" endpoint for  USEAST?

@Ruoying, @jcothran and @vembus are USEAST data archive in a similar manner as SABGOM?

@kwilcox is interested in this too

https://github.com/ioos/secoora/issues/151

I guess people will let us know if they start archiving it.  Closing this.


Incompatibility exoplayer versions between expo-av in sdk 45 and react-native-track-player

Hi, I use track-player with expo, all works fine in sdk 44, now I need to upgrade and I've receive the following error:
java.lang.NoSuchMethodError: No virtual method setAudioAttributes(Lcom/google/android/exoplayer2/audio/AudioAttributes;)V in class Lcom/google/android/exoplayer2/SimpleExoPlayer; or its super classes (declaration of 'com.google.android.exoplayer2.SimpleExoPlayer'

I've tried also to upgrade track-player to rc-4, but when I build my app I receive the error: duplicate class, related always to exoplayer.
Someone may help me to fix that?

Closing as a duplicate
https://github.com/doublesymmetry/react-native-track-player/issues/1418


Backup to cloud storage?

Would it be possible to do a test when backing up to cloud storage? As long as your local internet does not charge you for bandwidth, you can use Oracle Cloud Infrastructure as the target to get 10GB free storage, so that you don't have to pay for the tests, although Oracle may charge you for API calls. Scaleway offers free 75GB storage, which can be used too. Scaleway also does not charge for API calls.
I am happy to put some money in the pot to help fund this test.

bupstash currently doesn't have cloud storage other than what is offered at https://bupstash.io/managed.html

bupstash can be excluded from cloud storage tests, in that case, or just use bupstash.io. Cloud storage tests to me seem important, as most of these programs are intended for backing up to the cloud (aside from bupstash and borg to a limited extent).

@basldfalksjdf Would a local minio S3 server do the job ?

AFAIK, bupstash and borg both only support their own server implementation over SSH.
Indeed rclone makes it possible to replicate those repos into the cloud with various providers, but that's not really fair when it comes to speed benchmarking.
I also somehow assume that mounting an rclone target and creating a repo in such a mountpoint to simulate "local filesystem" backups could be quite slow.
@ThomasWaldmann Is my assumption above right ? If not, I'd mount a minio S3 server via rclone on the source server, and let borg backup into it
@andrewchambers If the above statement doesn't work, I'd happily use a managed bupstash account.

borg only supports a directory as repo storage or a remote borg process reachable via ssh (the latter is offered by some providers like borgbase.com, hetzner storage box, rsync.net).
one can use all sorts of stuff for the "directory", including directories on network or cloud filesystems, but it is the users responsibility then to choose something that actually works reliably.
i don't use rclone myself, so i can't comment on that.

Having previously benchmarked these systems (see this post on Restic vs. Kopia), self-hosted Minio doesn't always work because one can be limited by local IO bandwidth at times. Using a real scale-out storage system helps projects like Kopia that can efficiently utilize this.
I really do believe we should try and test systems against the best backend storage system they support.  Otherwise, we might unconsciously be testing a lowest common denominator or not actually testing the backup system but instead the backend storage system. I am not saying that these problems cannot be worked around but do need a lot more thought.

I already switched backend for restic and kopia, to their specific HTTPS implementation.
For now, kopia's speed on HTTPS was worse than SFTP, I'm still investigating, see https://github.com/kopia/kopia/issues/2372
So basically I think I'll stick with what the author thinks is the best, being AFAIK:

SSH + borg serve for borg
SSH + bupstash serve for bupstash
HTTPS via rest-server for restic
HTTPS via kopia serve for kopia
SFTP for duplicacy (they don't seem to have a preferred backend)

The idea is to keep self hosted backends.
I can add optional S3 benchmarks for restic, kopia and duplicacy.
I will be limited be indeed limited by my local hardware when using minio.
Then again, once the script supports S3 storage buckets, I can redo the test with some cloud provider, as long as I don't pay for doing benchmarks ;)


Add sort and limit on the /agent_configurations endpoint

Description

In the new designs, showcasing authors is a key feature across various scenarios, including our new landing page where we want to highlight four assistants. Given that computing the most recent authors can be quite demanding on resources, we're looking to avoid this computation for every assistant. This PR introduces a way for sorting and limiting within the /agent_configurations endpoint. It's important to note that the intention here isn't to support full pagination, as our primary sorting (priority) method doesn't align with MySQL. We might want to reconsider our our sorting to lean toward a usage-based sort.
With this update, we will execute two separate queries to populate the new conversation view:

one for the top two global assistants sorted by priority
another for two custom assistants sorted by alphabetical order.

Risk

Deploy Plan

Just to make sure I understand correctly the idea is to filter the output of getAgentConfigurations to at most k assistants so that we can call that endpoint with withAuthors=true and only compute that for the k assistants?

Correct, this is a temporary hack until we talk more about how we want to sort the assistants. I tried to get some more context around the current sort used but no one seems to recall exactly the sequence after dust first and gpt4 second 😅.

LGTM 👍 🙏 Test on front-edge first!

Tested on preprod.


FTPError: 421 No transfer timeout

It occurs with "Server sent FIN packet error." (of basic-ftp)
I found it occurs when this package creates folders for a long time.
Usually, when combined with GitHub actions, it takes over 10 minutes to create 200 ~ 300+ folders.

Here is a rapid solution to resolve this, but we need a better solution.
Changing syncProvider.ts like below.
...

 // create new folders
  for (const file of diffs.upload.filter(item => item.type === "folder")) {
      await this.createFolder(file.name);
      await this.uploadFile('dummy.txt', "upload"); // to prevent "421 No transfer timeout"
  }

...

This is a common error, it's due to routers/firewalls killing the connection. It happens on large file uploads as well but is dependent on the network from github->ftp server so it's extremely hard to recreate.
We can send a NOOP command via basic-ftp. I'd like to have a generalized solution because as I said this is a problem on more than just folder creation.
Have  you been able to recreate this only when creating a large number of files?
NOOP FTP command
The NOOP command does not cause the server to perform any action beyond acknowledging the receipt of the command. This command can be issued to the server to prevent the client from being automatically disconnected for being idle. It can also prevent modern routers/firewalls from closing a connection that it perceives as being idle as well.
Common responses:
421
500

Yes, I faced this issue an only a large number of files with a lot of subdirectories. (like deploying built files.)