[HOLD for payment 2023-06-30] [$1000] Android - Share code - Copied link has NOT staging label

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Issue found when executing PR https://github.com/Expensify/App/pull/19249
Action Performed:

Open the App
Login with any account
Go to settings > Share code
Click on "Copy URL to clipboard"
Go any chat.
Paste the link.
Verify that the url is treated as a link

Expected Result:
Copied link has staging label
Actual Result:
Copied link has NOT staging label
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

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

Version Number: <IP_ADDRESS>
Reproducible in staging?: Yes
Reproducible in production?: n/a
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://platform.applause.com/services/links/v1/external/f2c90b9aef4ae82b8e2a172f074f90a3824b4b9a476747a628ef41eed4bafad8
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01015fed2b575db172
Upwork Job ID:<PHONE_NUMBER>223589376
Last Price Increase: 2023-06-08

@kbecciv I don't see this issue when I try it, or at least I am not seeing different things in each account. I sent the link from staging on one account, and it didn't show staging in the URL. Then when I went to the recipient's account I also didn't see staging.

Is the issue that the URL is different in one view v. the other, or that it should showing staging in both URLs?

got clarity in slack, moving on!

@kevinksullivan could you please share the insights that you got here, with steps to reproduce. I am not able to reproduce it.
Thanks!

Proposal
Please re-state the problem that we are trying to solve in this issue.
Share Code - Copied link does not have staging label on Android devices when the app is run in debug mode.
What is the root cause of that problem?
The root cause of the problem is that when the app is run in debug mode in android devices, the environment file is not properly set here
What changes do you think we should make in order to solve the problem?
Replace the envConfigfiles for debug from .env to .env.staging here
debug: ".env.staging",
Also, add the following line:
apply from: project(":react-native-config").projectDir.getPath() + "/dotenv.gradle"
What alternative solutions did you explore? (Optional)

@rojiphil I think I agree with the .env file changes but I am not convinced if we should just change it to .env.staging for debug mode. The reason being, what if I am running a local build?

apply from: project(":react-native-config").projectDir.getPath() + "/dotenv.gradle"

And what's the reasoning for changing the filepath from top to bottom?

@mananjadhav Thanks for your feedback.

And what's the reasoning for changing the filepath from top to bottom?

Adding at the top does not help in reading the config file whereas adding to the bottom helps. Attaching the build output for your reference.

I think I agree with the .env file changes but I am not convinced if we should just change it to .env.staging for debug mode. The reason being, what if I am running a local build?

Not sure if I understood your comment correctly. Did you mean the local release build as shown here?

Not the local release build, but local debug build will always use staging env? I don't think we would want that.

@kbecciv I check this issue and see that:

When I use file .env with content to be copied from .env.staging. This bug doesn't occur. Copied link has staging label.

When I use file .env with content to be copied from .env.production. This bug will occur.

So, I think that copied link has staging label only to be shown in staging environment.

Not the local release build, but local debug build will always use staging env? I don't think we would want that.

@mananjadhav We can set the local environment variable for config files and run the debug version with staging or production configuration file like this in package.json
    "android-staging": "scripts/set-pusher-suffix.sh && export ENVFILE=.env.staging && npx react-native run-android --port=8083",
    "android-production": "scripts/set-pusher-suffix.sh && export ENVFILE=.env.production && npx react-native run-android --port=8083",

I think, this would resolve the problem. Let me know if this is fine and I can update the proposal accordingly.

I am going to take an opinion from @alex-mechler if we're okay to update the package.json.

Contributor details
MyeExpensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~01fcd9ed589276332f

If updating the package.json solves the root cause of this, we are okay to change it

Still looking for / reviewing proposals

@alex-mechler, @mananjadhav
I thought, my proposal here along with  this comment  resolves the problem.
Or am I missing something here? Please let me know.

Oh, I had missed that, sorry about that! @mananjadhav Can you re-review proposals based on https://github.com/Expensify/App/issues/19464#issuecomment-1568938289

@mananjadhav Bump :)

@rojiphil @alex-mechler thanks for the patience here, but I think it wouldn't make sense to update package.json unless we've run out of all the options. I think it is straight forward right now to just run npm run android. I also don't think android command is the problem because when we run staging builds I am assuming we use android-build commands.
@alex-mechler ?

@mananjadhav Ok. So, if we have to leave the package.json as it is and allow npm run android to use the staging environment, we can update the .env to .env.staging in build.gradle file. And, for use cases where there is a need to run a debug build with a production configuration file, we can also include the details in the relevant documentation. Would this be good enough?

I also don't think android command is the problem because when we run staging builds I am assuming we use android-build commands.

We build with fastlane android for deploys
https://github.com/Expensify/App/blob/bfdb3f10367441f3fc9e66fa995167c55e44c9ef/.github/workflows/platformDeploy.yml#L59-L70

@mananjadhav @alex-mechler Let me try to summarize all the currently available options:
a) npm run android:
Here, as proposed already, setting .env.staging in build.gradle will ensure that it will work with the staging environment. I think it makes sense to use a staging environment here as it is a debugging setup. What are your thoughts?
Also, would there be any use case that would require us to test the debugging setup with the production environment?
And, even if we have to support testing the debugging setup with the production environment, we can use the following command: "android-production": "scripts/set-pusher-suffix.sh && export ENVFILE=.env.production && npx react-native run-android --port=8083". This can either be documented or added to package.json
b) npm run android-build: This is used to build a local release build via Fastlane. Currently, it uses a production environment for the local build.  Since it is meant to build a local build, I think, it should also be using a staging environment. What are your thoughts here?
Further, if we decide to add support for the other environment too, we can add an additional lane in Fastfile with ENV["ENVFILE"]= pointing to the correct environment.
c) For deployment purposes as mentioned here
I think, all deployments, whether it is beta or production, should point to the production environment only as it is done currently. For production deployment, there is no question about using it with a staging environment. But, then, is there any use case that would demand the need for using beta deployments with a staging environment?
d) Any other points?
As @MelvinBot suggested, I too agree that getting on to Slack will help us align faster on the above. Please let me know.

@mananjadhav have you gotten a chance to review @rojiphil 's response?

I did review their comment, and at the second thought I think we should just Do nothing for this one.  I've started a slack thread here

still chatting in that ^ slack thread

As discussed on slack thread, working on updating the proposal based on Environment.getEnvironment

@mananjadhav I have updated the proposal. Kindly review.

@mananjadhav Updated the proposal

@alex-mechler @rojiphil's updated proposal would work. @rojiphil I think in terms of code it would be better to take this out in a function. If a function already exists, we leverage that or add like a utils?
All yours.

Offers sent @mananjadhav @rojiphil

@kevinksullivan you sent me an offer instead of @mananjadhav 😂

well shoot 😅 , fixing that now

@kevinksullivan, I have been assigned the work here. Also, I had applied in upwork.
Not sure what is the confusion here.
Please clarify

@rojiphil sorry for the confusion, I'm not sure what happened. I just sent another job offer. Let me know when you see/accept it.

@kevinksullivan Saw the offer and accepted. Thanks.

@flodnv added engineering label to have someone step in on the PR review for Alex.
https://github.com/Expensify/App/pull/21107

Waiting 6 days for any regressions

Paid @mananjadhav  on New Dot

@kevinksullivan  Gentle reminder as I am also awaiting payment.

hi @mananjadhav can you finish out the steps above please? Thanks!

@rojiphil sorry for the confusion here. A few weeks ago it seems I created another job for you but I'm not seeing it. Do you have an upwork job for this, and can you provide the link here? If not I'll just have to create another one.

@kevinksullivan Here is the link to the Upwork job.
I have also sent you a message on Upwork if that helps in tracking within Upwork.

Yes @kevinksullivan, I'll post an update tomorrow.

Thanks @rojiphil , all set.

Thanks @kevinksullivan @mananjadhav @AndrewGable @alex-mechler @MelvinBot. This was my first contribution to Expensify. Love the fairness, transparency, and process-oriented approach here.

Ohh that's good to hear @rojiphil. thanks for the patience on this one and appreciate your contribution. Welcome to the community. Looking forward to working with you more :)

In this PR, we added a fixed variable NEW_EXPENSIFY, which isn't set based on the environment. I wouldn't treat this so much as bug as we were on the fence to even fix this. We fixed this for uniformity.
I don't think we need a regression test for this one. @flodnv @kevinksullivan wdyt?

Agreed

yup, agree @mananjadhav

Closing out!


Remove requests dependency?

I'm trying out the collectd-cloudwatch plugin and it seems like it is just what I need. I've run into a number of frustrating setup pains however, particularly around installing requests, which is the only external dependency (disclaimer: I am not a python developer so I'm kind of stumbling through this)
Some excepts:
[root@ip-10-0-203-249 ec2-user]# python ./setup.py
Installing dependencies ... OK
Installing python dependencies ... OK
Downloading plugin ... OK
Extracting plugin ... OK
Moving to collectd plugins directory ... OK
Copying CloudWatch plugin include file ... OK
Traceback (most recent call last):
  File "./setup.py", line 658, in <module>
    main()
  File "./setup.py", line 651, in main
    install_plugin()
  File "./setup.py", line 576, in install_plugin
    supply_config()
  File "./setup.py", line 592, in supply_config
    _prepare_plugin_config(config)
  File "./setup.py", line 606, in _prepare_plugin_config
    InteractiveConfigurator(plugin_config, metadata_reader, COLLECTD_INFO).run()
  File "./setup.py", line 313, in run
    self._configure_region()
  File "./setup.py", line 341, in _configure_region
    region = self.metadata_reader.get_region()
  File "./setup.py", line 201, in get_region
    region = self._get_metadata(MetadataReader._REGION_METADATA_REQUEST)
  File "./setup.py", line 220, in _get_metadata
    from requests import Session, codes
  File "/usr/local/lib/python2.7/site-packages/requests/__init__.py", line 74, in <module>
    raise RuntimeError('Requests dependency \'chardet\' must be version >= 3.0.2, < 3.1.0!')
RuntimeError: Requests dependency 'chardet' must be version >= 3.0.2, < 3.1.0!

Doing sudo pip install chardet=3.0.4 yields this:
[ec2-user@ip-10-0-203-249 ~]$ sudo pip install chardet==3.0.4
Requirement already satisfied: chardet==3.0.4 in /usr/local/lib/python2.7/site-packages

So the right version of chardet is installed in the directory /usr/local/lib/python2.7/site-packages, however, there is another version installed to /usr/lib/python2.7/dist-packages which is version 2.0.1.
The setup.py script is not loading the correct version because the sys.path is listing dist-packages first. Now, I think I could do sudo easy_install -U chardet=3.0.4 and try to upgrade the version that is in /usr/lib/python2.7/dist-packages but I don't know if that will break other python scripts in my system that depend on that specific version of chardet.
I ran the setup.py script in a virtualenv to try to get the initial setup working, which worked pretty well until the setup.py script tried to restart collectd.
Plugin configuration written successfully.
Creating backup of the original configuration ... OK
Replacing collectd configuration ... OK
Replacing whitelist configuration ... OK
Stopping collectd process ... NOT OK
Starting collectd process ... NOT OK
Installation cancelled due to an error.
Executed command: '/usr/sbin/collectd'.
Error output: '[2017-06-13 01:04:17] plugin_load: plugin "logfile" successfully loaded.
Error: Reading the config file failed!
Read the logs for details.'.

I saw this error in the collectd.log file:
[2017-06-13 00:26:39] [error] python plugin: Error importing module "cloudwatch_writer".
[2017-06-13 00:26:39] [error] Unhandled python exception in importing module: ImportError: No module named requests
[2017-06-13 00:26:39] [error] Traceback (most recent call last):
[2017-06-13 00:26:39] [error]   File "/opt/collectd-plugins/cloudwatch_writer.py", line 10, in <module>
    from cloudwatch.modules.configuration.confighelper import ConfigHelper
[2017-06-13 00:26:39] [error]   File "/opt/collectd-plugins/cloudwatch/modules/configuration/confighelper.py", line 4, in <module>
    from metadatareader import MetadataReader
[2017-06-13 00:26:39] [error]   File "/opt/collectd-plugins/cloudwatch/modules/configuration/metadatareader.py", line 2, in <module>
    from requests import Session, codes
[2017-06-13 00:26:39] [error] ImportError: No module named requests
[2017-06-13 01:04:17] [info] plugin_load: plugin "cpu" successfully loaded.
[2017-06-13 01:04:17] [info] plugin_load: plugin "df" successfully loaded.
[2017-06-13 01:04:17] [info] plugin_load: plugin "memory" successfully loaded.
[2017-06-13 01:04:17] [info] plugin_load: plugin "swap" successfully loaded.

So whatever path collectd is using to run python doesn't even have requests installed.
Okay so long story short, I think the setup process would be easier and less error prone if users didn't need to fuss with external dependencies and python paths to get this working. This is especially true because this python script and the collectd plugin depend on root's python environment.

Alternatively, rather than installing requests in the root python environment, it could be installed in the path where the signalfx collectd plugin lives, e.g. /opt/collectd-plugins. I just copied the requests library there and that solved all my issues.


Modal not closing when backdrop is tapped

Issue description

version #4.3.0
components: Modals
device: iphone (iOS 9.3.5), only occurs in iphone browsers (no matter the browser is Chrome or Safari)
the same issue had been fixed in react-bootstrap before: https://github.com/react-bootstrap/react-bootstrap/issues/150

Steps to reproduce issue

open the sample https://reactstrap.github.io/components/modals/
launch a modal that has a backdrop
tap the backdrop to close the modal, not working

Unable to reproduce on iPhone6 (iOS 10.3) Safari.

Thanks for the info! I was pretty sure I also was able to do this on a recent IOS version. It would be good to isolate the versions affected and whether bootstrap v4 supports those versions of browsers to prioritize this.

I encounter the problem in following devices:
(1) iphone 5s (iOS 9.3.5) safari & chrome

This is an older issue that hasn't been addressed yet. I pulled up the modal component on my iPhone X (iOS 13.1.3) and when the backdrop is set to "true", I am able to close out the modal by clicking anywhere else on the screen. When it is set to "false" or "static", I am unable to do this and am forced to close by clicking one of the buttons. This doesn't seem to be an issue anymore. Can it be closed?

I'm closing this since the the issue is no longer active and it appears it was answered above. Please comment and it will be opened if you feel the issue has not been resolved / the question has not been answered.


Add linting, remove babel config, add package lock

Totally chill if you don't want to merge this, but I thought it would be nice to get some linting in place. I overrode some prettier options to match the current style more closely

Totally chill if you don't want to merge this, but I thought it would be nice to get some linting in place. Let me know if you want me to add some overrides of the default prettier rules to match the existing code style a bit more (single quotes, four spaces perhaps)

Such big changes are generally undesirable, but let's roll with it…


[bug?] custom directives have their first argument cut off during introspection

$ pip freeze | grep strawberry
strawberry-graphql==0.96.0

Here's a quick repro:
import strawberry
from strawberry.directive import DirectiveLocation
from typing import Optional

@strawberry.directive(locations=[DirectiveLocation.QUERY])
def hello_world(
    foo: str,
    bar: str,
    baz: str,
):
    pass

@strawberry.type
class Query:
    _service: Optional[str]

schema = strawberry.federation.Schema(query=Query, directives=[hello_world])
print(schema.execute_sync("""
    query SubgraphIntrospectQuery {
        _service {
            sdl
        }
    }
""").data['_service']['sdl'])

$ python test.py
directive @helloWorld(bar: String!, baz: String!) on QUERY

type Query {
  _service: _Service!
  Service: String
}

scalar _Any

type _Service {
  sdl: String!
}

Let's zoom in on that directive SDL: directive @helloWorld(bar: String!, baz: String!) on QUERY - what happened to  thefoo arg?
I guess this behaviour is coming from the slicing here: https://github.com/strawberry-graphql/strawberry/blob/b8ead94d0cceb9eb5f9a6ea5a37123efd9bf48a3/strawberry/directive.py#L26

@magicmark that's probably a bug, the code currently assumes that the first argument in the directive is the value returned from the resolver, for example:
@strawberry.directive(
    locations=[DirectiveLocation.FIELD], description="Make string uppercase"
)
async def uppercase(value: str):
    return value.upper()

We should probably change this logic to use the name of the argument 🤔

Maybe related: I see there's two interfaces for defining directives - the @strawberry.directive decorator used above (as described here), and the @strawberry.schema_directive approach documented here (but not navigable via the sidebar?) - I am having trouble running the example from the docs tho 🤔

import strawberry
from strawberry.schema_directive import Location
from typing import Optional

@strawberry.schema_directive(locations=[Location.OBJECT])
class Keys:
    fields: str

@strawberry.type(directives=Keys(fields="id"))
class User:
    id: strawberry.ID
    name: str

@strawberry.type
class Query:
    _service: Optional[str]

    @strawberry.field()
    def me() -> User:
        return User(id="1", name="mark")

schema = strawberry.federation.Schema(query=Query)
print(schema.execute_sync("""
    query SubgraphIntrospectQuery {
        _service {
            sdl
        }
    }
"""))

$ python test.py
Traceback (most recent call last):
  File "test.py", line 25, in <module>
    schema = strawberry.federation.Schema(query=Query)
  File "/nail/home/markl/pg/i18n_strings/virtualenv_run/lib/python3.7/site-packages/strawberry/federation/schema.py", line 32, in __init__
    self._extend_query_type()
  File "/nail/home/markl/pg/i18n_strings/virtualenv_run/lib/python3.7/site-packages/strawberry/federation/schema.py", line 62, in _extend_query_type
    entity_type = _get_entity_type(self.schema_converter.type_map)
  File "/nail/home/markl/pg/i18n_strings/virtualenv_run/lib/python3.7/site-packages/strawberry/federation/schema.py", line 111, in _get_entity_type
    for type in type_map.values()
  File "/nail/home/markl/pg/i18n_strings/virtualenv_run/lib/python3.7/site-packages/strawberry/federation/schema.py", line 112, in <listcomp>
    if _has_federation_keys(type.definition)
  File "/nail/home/markl/pg/i18n_strings/virtualenv_run/lib/python3.7/site-packages/strawberry/federation/schema.py", line 138, in _has_federation_keys
    return any(_is_key(directive) for directive in definition.directives or [])
TypeError: 'StrawberrySchemaDirective' object is not iterable

Maybe related: I see there's two interfaces for defining directives - the @strawberry.directive decorator used above (as described here), and the @strawberry.schema_directive approach documented here (but not navigable via the sidebar?)
Yes, that's on purpose, I wanted to test schema directive a bit more :)

Schema directives are directives that are printed in the schema (like the ones used by apollo federation)
(Client) directives are directives used by the clients to change the execution (for example for converting something to uppercase)

I am having trouble running the example from the docs tho 🤔

strawberry.type accepts a list of directives:
@strawberry.type(directives=[Keys(fields="id")])

See: https://la4de.github.io/strawberry-playground/#UEsDBAoAAAAAANqsVlQgaUU4EgAAABIAAAAQAAAAcmVxdWlyZW1lbnRzLnR4dHN0cmF3YmVycnktZ3JhcGhxbFBLAwQKAAAAAADarFZU+fgCCOMBAADjAQAACQAAAHNjaGVtYS5weWltcG9ydCBzdHJhd2JlcnJ5CmZyb20gc3RyYXdiZXJyeS5zY2hlbWFfZGlyZWN0aXZlIGltcG9ydCBMb2NhdGlvbgpmcm9tIHR5cGluZyBpbXBvcnQgT3B0aW9uYWwKCgpAc3RyYXdiZXJyeS5zY2hlbWFfZGlyZWN0aXZlKGxvY2F0aW9ucz1bTG9jYXRpb24uT0JKRUNUXSkKY2xhc3MgS2V5czoKICAgIGZpZWxkczogc3RyCgoKQHN0cmF3YmVycnkudHlwZShkaXJlY3RpdmVzPVtLZXlzKGZpZWxkcz0iaWQiKV0pCmNsYXNzIFVzZXI6CiAgICBpZDogc3RyYXdiZXJyeS5JRAogICAgbmFtZTogc3RyCgpAc3RyYXdiZXJyeS50eXBlCmNsYXNzIFF1ZXJ5OgogICAgX3NlcnZpY2U6IE9wdGlvbmFsW3N0cl0KCiAgICBAc3RyYXdiZXJyeS5maWVsZCgpCiAgICBkZWYgbWUoKSAtPiBVc2VyOgogICAgICAgIHJldHVybiBVc2VyKGlkPSIxIiwgbmFtZT0ibWFyayIpCgoKCgpzY2hlbWEgPSBzdHJhd2JlcnJ5LmZlZGVyYXRpb24uU2NoZW1hKHF1ZXJ5PVF1ZXJ5KVBLAwQKAAAAAADarFZUbsyYDSEAAAAhAAAACQAAAHF1ZXJ5LmdxbHsKICB1c2VyIHsKICAgIG5hbWUKICAgIGFnZQogIH0KfVBLAwQKAAAAAADarFZUqLu+cwMAAAADAAAADgAAAHZhcmlhYmxlcy5qc29uewp9UEsBAhQACgAAAAAA2qxWVCBpRTgSAAAAEgAAABAAAAAAAAAAAAAAAAAAAAAAAHJlcXVpcmVtZW50cy50eHRQSwECFAAKAAAAAADarFZU+fgCCOMBAADjAQAACQAAAAAAAAAAAAAAAABAAAAAc2NoZW1hLnB5UEsBAhQACgAAAAAA2qxWVG7MmA0hAAAAIQAAAAkAAAAAAAAAAAAAAAAASgIAAHF1ZXJ5LmdxbFBLAQIUAAoAAAAAANqsVlSou75zAwAAAAMAAAAOAAAAAAAAAAAAAAAAAJICAAB2YXJpYWJsZXMuanNvblBLBQYAAAAABAAEAOgAAADBAgAAAAA=

Ah thanks! I think maybe there's a typo in the docs:
-@strawberry.type(directives=Keys(fields="id"))
+@strawberry.type(directives=[Keys(fields="id")])

which could be why my copy/pasted thing wasn't working

(btw I love this project, the documentation looks amazing and has been super easy to onboard to. Massive <3)

Ah thanks! I think maybe there's a typo in the docs then?
-@strawberry.type(directives=Keys(fields="id"))
+@strawberry.type(directives=[Keys(fields="id")])

which could be why my copy/pasted thing wasn't working

yup! feel free to send a PR for a fix if you want 😊
also let me know how schema directives are working for you, happy to fix issues 😊

(btw I love this project, the documentation looks amazing and has been super easy to onboard to. Massive <3)

Thanks <3

@magicmark that's probably a bug, the code currently assumes that the first argument in the directive is the value returned from the resolver, for example:
@strawberry.directive(
    locations=[DirectiveLocation.FIELD], description="Make string uppercase"
)
async def uppercase(value: str):
    return value.upper()

We should probably change this logic to use the name of the argument 🤔

Looking at taking a stab at a fix for this - to clarify the (breaking?) logic you want: to receive the parent value (e.g. the value returned from the resolver that we're directifying), the directive function must have a variable named value (could be in any position) and we'll pass that in as a named argument. Then we can change this logic annotations = dict(islice(annotations.items(), 1, None)) to grab all the arguments, but filter out any argument named value
does this sound correct? my understanding:
pros: simple+understandable logic, works similar to the root param for resolvers
con: may be a breaking change and prevent folks from using that identifier as a directive arg name in the schema

Looking at taking a stab at a fix for this - to clarify the (breaking?) logic you want: to receive the parent value (e.g. the value returned from the resolver that we're directifying), the directive function must have a variable named value (could be in any position) and we'll pass that in as a named argument. Then we can change this logic annotations = dict(islice(annotations.items(), 1, None)) to grab all the arguments, but filter out any argument named value
does this sound correct? my understanding:
pros: simple+understandable logic, works similar to the root param for resolvers
con: may be a breaking change and prevent folks from using that identifier as a directive arg name in the schema

yes, that's all correct :)
I was thinking about using a custom type for annotating root and value for example:
def resolver(instance: Root[MyType]) -> str: ...

def directive(v: FieldValue[str]) -> str: ...

what do you think of this approach? we could do this for the info parameter too :)
/cc @strawberry-graphql/core

what do you think of this approach? we could do this for the info parameter too :)

You mean, if the argument is typed as Root (and similary, as Info for info), it doesn't matter if it is named root or anything, it will be assigned the root value?
If so, I like it! I'm just worried regarding backwards compatibility and how much we should care about it in this stage (since v1.0 hasn't been released yet).
Another possibility for getting root and info would be to use contextvars. That would allow us to avoid having to do all that argument magic and retrieve the current root/info when required from the context. It could be exposed as strawberry.info() and strawberry.root(), which would basically resolve their contexts, or even in a strawberry.[context|ctx] object with an info/root/anything else properties.

what do you think of this approach? we could do this for the info parameter too :)

You mean, if the argument is typed as Root (and similarly, as Info for info), it doesn't matter if it is named root or anything, it will be assigned the root value?
If so, I like it! I'm just worried regarding backwards compatibility and how much we should care about it in this stage. Since v1.0 hasn't been released yet, maybe this shouldn't be a concern?

Yes :) We could gracefully deprecate using root without typing it as Root and keep the old behaviour working until v1.0 :)
We could also provide a codemod, but not sure how much work that would be :)

Another possibility for getting root and info would be to use contextvars. That would allow us to avoid having to do all that argument magic and retrieve the current root/info when required from the context. It could be exposed as strawberry.info() and strawberry.root(), which would basically resolve their contexts, or even in a strawberry.[context|ctx] object with an info/root/anything else properties.

I'm not familiar with contextvar so I'm not sure if they would work in all the cases :)
aslo info and root are based on the current field/resolver, how would you update the contextvar?

I'm not familiar with contextvar so I'm not sure if they would work in all the cases :)
aslo info and root are based on the current field/resolver, how would you update the contextvar?

I have started messing around with contextvars lately, and AFAIK, they should work in all cases. It is actually built for this use case in mind!
We just need to set the context values during the field resolution. It will also keep each async context separated, so 2 or more async fields being resolved at the same time will each have their own contexts.
Since code speaks better than words, I wrote a small proof of concept (https://github.com/strawberry-graphql/strawberry/pull/1672) and some tests to show how it works. Note that it works for sync/async resolvers, and the more interesting one is the no_params_field, where I could retrieve its root and info values without receiving them by args :)

contextvars seems cool! my only thought is that it's a slight mind-bender coming from graphql-js and other frameworks where stuff is threaded around as params to resolvers, which are thought of as pure functions.
I probably don't have enough context (heh) yet on the codebase to manage such a change, and it looks like @bellini666 already started down this line, so I won't tread on their toes
I probably could manage a PR to do the first thing tho (comparing the params against their types, introducing a newValue type? although I think it would basically have to be Any...)
Is this worth doing or should we just focus on the contextvars approach?

I probably don't have enough context (heh) yet on the codebase to manage such a change, and it looks like @bellini666 already started down this line, so I won't tread on their toes

Oh, it wasn't my idea to define the line we are going to follow, it was really just a quick proof of concept that can be thrown in the garbage if people don't like it :)

contextvars seems cool! my only thought is that it's a slight mind-bender coming from graphql-js and other frameworks where stuff is threaded around as params to resolvers, which are thought of as pure functions.
I probably don't have enough context (heh) yet on the codebase to manage such a change, and it looks like @bellini666 already started down this line, so I won't tread on their toes
I probably could manage a PR to do the first thing tho (comparing the params against their types, introducing a newValue type? although I think it would basically have to be Any...)
Is this worth doing or should we just focus on the contextvars approach?

If you don't mind it would be nice to have a PR for both, I'm leaning towards using types and arguments, but I need to think about a bit more, will try to make an issue detailing both approaches this weekend so we don't spent too much time fixing this issue with directives[1] 😊
[1] worst case we do the same thing we do for resolvers for the time being :)

Ok I think I need some help, I'm pretty new to mypy types tbh.
we're trying for something like this right?:
@strawberry.directive(
    locations=[DirectiveLocation.FIELD],
    description="Make string uppercase",
)
def uppercase(value: DirectiveValue[str], example: str):
    return value.upper()

So then how do we define DirectiveValue 🤔
vague attempt:
T = TypeVar('T')
class DirectiveValue(Generic[T]):
    ...

test: DirectiveValue[str] = "sdfdsf"

but then mypy throws:
error: Incompatible types in assignment (expression has type "str", variable has type "DirectiveValue[str]")

(makes sense cos there's no way to propagatee" the generic str through and tell mypy that the test variable is actually a str)
this is more of a general mypy question but i'm not exactly sure how to define a transparent container for a generic that just forwards the type along to the underlying variable - a genericable type alias (if that's even theright terminologyy)
nothing jumps out at me in https://mypy.readthedocs.io/en/stable/generics.html

@magicmark if this is blocking you we can use the same pattern for the root value in resolvers and then migrate to the new approach in future :)

@skilkis sure, go for it 😊

@bellini666 I spent some time to understand what you wrote and it's really cool stuff, contextvars seem awesome and I can't wait to use them in other projects! Just to confirm, was your intention to eventually remove info and root arguments from resolvers?

Yeah, contextvars works really well for cases like this! :)
The removal of info and root arguments from resolvers is a possibility (not mandatory) if we go to the contextvars route. The major pro here is that we can simplify the resolvers a lot by removing the info/root "magic" from them, and also we can access the current root/info at any place, not only inside the resolver itself (as long as we are currently resolving it).

@magicmark

So then how do we define DirectiveValue 🤔
i did try to type it correctly as well, but didn't figure anything out. it should be possible if we make mypy plugin logic, but thats not very convenient and won't work right with pyright / pycharm.

my only thought is that it's a slight mind-bender coming from graphql-js and other frameworks where stuff is threaded around as params to resolvers, which are thought of as pure functions.

I also agree with this.  would prefer it to come from the arguments.  though at worst case in my codebase i would only do the magic retrieval of context variables in my strawberry layer.

@magicmark

So then how do we define DirectiveValue 🤔

i did try to type it correctly as well, but didn't figure anything out. it should be possible if we make mypy plugin logic, but thats not very convenient and won't work right with pyright / pycharm.

It would the same as Private :) https://github.com/strawberry-graphql/strawberry/blob/316ccb2d3cf1082969da0721bc494eb002188883/strawberry/private.py#L10-L13
This should be supported by all type checkers 😊

my only thought is that it's a slight mind-bender coming from graphql-js and other frameworks where stuff is threaded around as params to resolvers, which are thought of as pure functions.

I also agree with this. would prefer it to come from the arguments. though at worst case in my codebase i would only do the magic retrieval of context variables in my strawberry layer.

+1, I still didn't have time to get more familiar with contextvar, I wonder if there's any performance implication too
I'd personally go for "dependency injection style" params, seems easier to reason about as a end user 😊

@patrick91 I've been really busy at work lately, but it gave me the time to think about this issue over quite a few lunch breaks and evenings 😄. I've come up with a solution for introducing a backwards-compatible way to declare DirectiveValue annotated value arguments based on the discussions above. This approach also works for Info annotated resolvers. Please see the PR above for details.
Also, I wasn't sure about how you want to handle deprecation (if at all) for value and info arguments without annotations. To serve as as an example of what we could do, I've included a deprecation warning stating that support will be dropped when v1.0 releases.

@skilkis, I'll take a look at this soon, I'll also chat with @bellini666 regards to context vars

@skilkis, I'll take a look at this soon, I'll also chat with @bellini666 regards to context vars

Just ping me to chat :)


Add aad namespace and groups

Hi KonaTeam,
First off, thank you for the hard work you've put into this library. Not only has it been relatively easy to get it working with AzureAD, but it works better than the AzureAD Omniauth library provided by Microsoft.
This PR introduces the following two features/breaking changes:

Introduction of the aad_ namespace to the Omniauth provider configuration. This allows the configuration to be less ambiguous and helps avoid key collisions.

Groups support. Note that this is a decent breaking change and can use some more testing. The long story short is that the raw_info method now decodes the access_token with a focus on the id_token param. This is where the groups (<List<GUID>>) is provided, along with other "standard" claims.

I understand that it may not be reasonable to merge in this PR because groups aren't necessarily in the "standard set" of the Omniauth hash and the namespace change may be too breaking for most users. However, I do ask that this PR (regardless of merge or closed state) is known among the maintainers in the case users need this functionality. It will also be searchable too, of course :).
Thanks,
Matthew

It could make sense to split this pull request. One for the group support and one for the proposed name change. This would increase the likelyhood of any of the changes to get merged.

Thanks for contributing. However, I no longer have time to maintain this gem. Your best bet is to fork it and consider publishing to RubyGems so others can benefit.


[BUG] [Docker] Cannot Start Main Process: exec container process /app/./upsnap: Operation not permitted

The bug
Hi I'm using podman to run the docker image on RHEL 9. The reason why I'm not using docker is because podman replaces docker completely on RHEL and it is a pain to switch to docker (on RHEL, docker is an alias to podman so installing docker will get podman installed by default). Plus, all of my other docker images works just fine using podman.
When I start the container it keeps says this
{"msg":"exec container process `/app/./upsnap`: Operation not permitted","level":"error","time":"2024-08-11T10:13:41.148512Z"}

Tried both rootless and running as root. SELinux not enabled.
Tried checking ls and I can confirm the binary file upsnap exists.
The mounted directory has 777 permission and is owned by the user when running rootless.
Any ideas?
The OS that UpSnap is running on
RHEL 9.4
Version of UpSnap
Latest from ghcr.io/seriousm4x/upsnap:4
Your docker-compose.yml content
version: "3"
services:
  upsnap:
    container_name: upsnap
    image: ghcr.io/seriousm4x/upsnap:4
    network_mode: host
    restart: unless-stopped
    volumes:
      - /mnt/apps/upsnap:/app/pb_data

Reproduction steps
1. Create folder /mnt/apps/upsnap
2. `chown` it to user
3. `chmod` it to 777
4. Turn off SELinux
5. Create `docker-compose.yml`
6. `sudo podman-compose up` or `podman-compose up`
7. Error shown and container not running.

Additional information
No response

Not quite sure why the path is showing as /app/./upsnap. There shouldn't be any dot in between. Maybe thats the issue?
Could you try running the executable directly from the latest release page?

I've found a workaround. Seems like on RHEL the compose file needs privileged: true to run propeerly.
services:
  upsnap:
    container_name: upsnap
    image: ghcr.io/seriousm4x/upsnap:4
    network_mode: host
    restart: unless-stopped
    volumes:
      - ./pb_data:/app/pb_data
    privileged: true


[TF] Removed 'HackyTensorflowMigrationSupport'.

@rxwei @pschuh Removed HackyTensorflowMigrationSupport.swift.
Friend PR: tensorflow/swift-apis#139.

@rxwei I update the dependency hash so we should be able to run tests now.

@swift-ci please clean test tensorflow Linux

@rxwei, this is a separate issue but for lack of better communication channel I'll post it here. I tried enabling compiler optimizations for the TensorFlow module by setting these flags:
list(APPEND swift_stdlib_compile_flags "-O" "-whole-module-optimization")

but I still get failures for multiple tests even though GPE is now gone. I believe we should start looking into why this happens as it could potentially have significant performance impact. One very simple test that fails with a set fault, for example, is this:
StringDescriptionTests.test("Vector") {
  do {
    let vector = Tensor<Int32>(ones: [4])
    expectEqual("[1, 1, 1, 1]", vector.description)
  }

  do {
    var vector = Tensor<Float>([1, 2, 3, 4])
    expectEqual("[1.0, 2.0, 3.0, 4.0]", vector.description)
    vector[1] = Tensor<Float>(-2)
    expectEqual("[ 1.0, -2.0,  3.0,  4.0]", vector.description)
  }

  // Test long vector (above 1000 scalar threshold).
  do {
    let vector = Tensor<Float>(repeating: 3, shape: [1001])
    expectEqual("[3.0, 3.0, 3.0, ..., 3.0, 3.0, 3.0]", vector.description)
  }
}

Again, this is separate from this PR so sorry for posting it here if it's confusing.

@rxwei @eaplatanios Is it OK to have known protocols and derived conformances for those protocols that are not part of stdlib?

@bgogul I believe that technically they are since TensorFlow is part of stdlib. They are just hosted in a separate repository.
Generally though, it'd be great if we found an elegant way to add support for such derivations at the language level, similar to what Scala supports, so that all this can be implemented in Swift. :)

I just pushed an edit that fixes the failing test. It only fails on Linux and I don't really understand why but it should be fine now.

@swift-ci please test tensorflow Linux

@swift-ci please test tensorflow


Níma: Refactor static content to a feature

Static content is registered for specific paths, and as such is not a good fit to be a feature

Will not fix


Failed check on function in if clause

TypeScript Version:  2.5.3
Code
if (Math.floor(1.2), 2) {
   // do something
}

Expected behavior:
error TS2695: Left side of comma operator is unused and has no side effects.
Actual behavior:

Nothing happened.
But can get error like this.

There are limits to things like call flow analysis, and this would be one of them.  While it might be potentially a logic error, what is a real world use case where this would occur.  CFA comes at a cost, and if this is not a common logic error, it is unlikely for it to be added to the compiler.

but I really did take a very long time to find this error in real world.
As you can see, I just made a example.

And Why if (1, 2 is error, but if (Math.floor(1.2), 2) can pass.

A simplified example is always good, but again, that is not very realistic or sensible code.  If you provided an example that was more realistic, then it might help identify how TypeScript could help in statically identifying issues.
There are trade-offs with CFA (see #9998).  This would require the ability to describe the return types of functions in truthy and un-truthy values to be evaluated at run time to produce the same error.  While Math.floor() is a built in function, the way TypeScript deals with it is like any other return, which is that it returns a number and when it does the analysis it cannot determine if that number will be 0 (falsey) or != 0 (truthy).
On the other hand, providing more than one statement to an if () expression is likely a static error that TypeScript could detect... I am not really sure any construct like if (foo, bar) { } would ever be desirable, even if it is valid syntax.

This is unrelated to if.
Math.floor(1.2), 2;
1, 2;

Note that the error message says "and has no side effects". TypeScript doesn't track what functions has side effects, so this error will only happen for an expression that obviously has no side effects such as null.
You may be interested in palantir/tslint#3250.

Thx，I got it.
😄

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.


ACME challenges stopped working after 1.13/1.14 update

ACME challenges stopped working on our Openshift cluster after operator upgrade to 1.13/1.14 version. It was working without problems with operator version 1.12 and stopped working after operator update to 1.13 version, still not working with 1.14.2 version.
Cluster version is Openshift: 4.12.47
operator tested is 1.14.2 (also did not work on 1.13.x versions).
Operator is installed via OLM.
Our observations:

Issuer is set up correctly and is registered correctly with digicert
Certificates are either created or trying to be renewed correctly
CertificateRequest is created and is approved by certmanager.io
Order is created and is in Ready state

After this, nothing happens. We expect a challenge to be created, with ACME challenge Pod, but this never happens and there seem to be no error messages or events whatsoever.
Here are the relevant logs:
[~]$ oc describe issuer digicert
Name:         digicert
Namespace:    test-mb-certificates
Labels:       <none>
Annotations:  <none>
API Version:  cert-manager.io/v1
Kind:         Issuer
Metadata:
  Creation Timestamp:  2024-02-23T09:32:03Z
  Generation:          1
  Resource Version:<PHONE_NUMBER>
  UID:                 d28f4f33-173e-44d1-b76b-bda007c50aed
Spec:
  Acme:
    Disable Account Key Generation:  true
    Email:                           xxx
    External Account Binding:
      Key Algorithm:  HS256
      Key ID:         xxx
      Key Secret Ref:
        Key:          secret
        Name:         digicert-creds
    Preferred Chain:
    Private Key Secret Ref:
      Name:  digicert-tls
    Server:  https://acme.digicert.com/v2/acme/directory/
    Solvers:
      http01:
        Ingress:
          Class:  openshift-default
Status:
  Acme:
    Last Private Key Hash:  xxx
    Last Registered Email:  xxx
    Uri:                    https://acme.digicert.com/v2/acme/account/xxx
  Conditions:
    Last Transition Time:  2024-02-23T09:32:05Z
    Message:               The ACME account was registered with the ACME server
    Observed Generation:   1
    Reason:                ACMEAccountRegistered
    Status:                True
    Type:                  Ready
Events:                    <none>

[Cluster: occ] [~]$ oc describe certificate testacme2-cez-cz
Name:         testacme2-cez-cz
Namespace:    test-mb-certificates
Labels:       <none>
Annotations:  <none>
API Version:  cert-manager.io/v1
Kind:         Certificate
Metadata:
  Creation Timestamp:  2024-02-23T09:35:37Z
  Generation:          1
  Resource Version:<PHONE_NUMBER>
  UID:                 1af0d9e3-75a4-40cc-8dd3-bae4817dd162
Spec:
  Common Name:  test2acme.cez.cz
  Dns Names:
    test2acme.cez.cz
  Issuer Ref:
    Name:  digicert
  Private Key:
    Algorithm:             ECDSA
    Size:                  256
  Revision History Limit:  2
  Secret Name:             testacme2-cez-cz
  Subject:
    Countries:
      CZ
    Organizations:
      ČEZ ICT Services
Status:
  Conditions:
    Last Transition Time:        2024-02-23T09:35:37Z
    Message:                     Issuing certificate as Secret does not exist
    Observed Generation:         1
    Reason:                      DoesNotExist
    Status:                      False
    Type:                        Ready
    Last Transition Time:        2024-02-23T09:35:37Z
    Message:                     Issuing certificate as Secret does not exist
    Observed Generation:         1
    Reason:                      DoesNotExist
    Status:                      True
    Type:                        Issuing
  Next Private Key Secret Name:  testacme2-cez-cz-56sk9
Events:
  Type    Reason     Age   From                                       Message
  ----    ------     ----  ----                                       -------
  Normal  Issuing    10m   cert-manager-certificates-trigger          Issuing certificate as Secret does not exist
  Normal  Generated  10m   cert-manager-certificates-key-manager      Stored new private key in temporary Secret resource "testacme2-cez-cz-56sk9"
  Normal  Requested  10m   cert-manager-certificates-request-manager  Created new CertificateRequest resource "testacme2-cez-cz-1"
[Cluster: occ] [~]$ oc describe certificaterequest testacme2-cez-cz-1
Name:         testacme2-cez-cz-1
Namespace:    test-mb-certificates
Labels:       <none>
Annotations:  cert-manager.io/certificate-name: testacme2-cez-cz
              cert-manager.io/certificate-revision: 1
              cert-manager.io/private-key-secret-name: testacme2-cez-cz-56sk9
API Version:  cert-manager.io/v1
Kind:         CertificateRequest
Metadata:
  Creation Timestamp:  2024-02-23T09:35:37Z
  Generation:          1
  Owner References:
    API Version:           cert-manager.io/v1
    Block Owner Deletion:  true
    Controller:            true
    Kind:                  Certificate
    Name:                  testacme2-cez-cz
    UID:                   1af0d9e3-75a4-40cc-8dd3-bae4817dd162
  Resource Version:<PHONE_NUMBER>
  UID:                     b5391d89-b556-4093-84ea-d503efaab800
Spec:
  Extra:
    authentication.kubernetes.io/pod-name:
      cert-manager-7d98dd6c49-z4vt5
    authentication.kubernetes.io/pod-uid:
      38ef976a-36c7-4cc9-86d3-8f7f12a261dd
  Groups:
    system:serviceaccounts
    system:serviceaccounts:cert-manager-operator
    system:authenticated
  Issuer Ref:
    Name:    digicert
  Request:   xxx
  UID:       5096ce5d-d03c-44b3-911e-2618833ebd20
  Username:  system:serviceaccount:cert-manager-operator:cert-manager
Status:
  Conditions:
    Last Transition Time:  2024-02-23T09:35:37Z
    Message:               Certificate request has been approved by cert-manager.io
    Reason:                cert-manager.io
    Status:                True
    Type:                  Approved
    Last Transition Time:  2024-02-23T09:35:37Z
    Message:               Waiting on certificate issuance from order test-mb-certificates/testacme2-cez-cz-1-1786450120: "ready"
    Reason:                Pending
    Status:                False
    Type:                  Ready
Events:
  Type    Reason              Age   From                                                Message
  ----    ------              ----  ----                                                -------
  Normal  WaitingForApproval  11m   cert-manager-certificaterequests-issuer-ca          Not signing CertificateRequest until it is Approved
  Normal  WaitingForApproval  11m   cert-manager-certificaterequests-issuer-acme        Not signing CertificateRequest until it is Approved
  Normal  WaitingForApproval  11m   cert-manager-certificaterequests-issuer-selfsigned  Not signing CertificateRequest until it is Approved
  Normal  WaitingForApproval  11m   cert-manager-certificaterequests-issuer-vault       Not signing CertificateRequest until it is Approved
  Normal  WaitingForApproval  11m   cert-manager-certificaterequests-issuer-venafi      Not signing CertificateRequest until it is Approved
  Normal  cert-manager.io     11m   cert-manager-certificaterequests-approver           Certificate request has been approved by cert-manager.io
  Normal  OrderCreated        11m   cert-manager-certificaterequests-issuer-acme        Created Order resource test-mb-certificates/testacme2-cez-cz-1-1786450120

[Cluster: occ] [~]$ oc describe order testacme2-cez-cz-1-1786450120
Name:         testacme2-cez-cz-1-1786450120
Namespace:    test-mb-certificates
Labels:       <none>
Annotations:  cert-manager.io/certificate-name: testacme2-cez-cz
              cert-manager.io/certificate-revision: 1
              cert-manager.io/private-key-secret-name: testacme2-cez-cz-56sk9
API Version:  acme.cert-manager.io/v1
Kind:         Order
Metadata:
  Creation Timestamp:  2024-02-23T09:35:37Z
  Generation:          1
  Owner References:
    API Version:           cert-manager.io/v1
    Block Owner Deletion:  true
    Controller:            true
    Kind:                  CertificateRequest
    Name:                  testacme2-cez-cz-1
    UID:                   b5391d89-b556-4093-84ea-d503efaab800
  Resource Version:<PHONE_NUMBER>
  UID:                     2537872f-0b0b-44fe-9c0e-be6c5bb872fc
Spec:
  Common Name:  test2acme.cez.cz
  Dns Names:
    test2acme.cez.cz
  Issuer Ref:
    Name:   digicert
  Request:  xxx
Status:
  Authorizations:
    Challenges:
      Token:        xxx
      Type:         http-01
      URL:          https://acme.digicert.com/v2/acme/challenge/xxx
      Token:        xxx
      Type:         dns-01
      URL:          https://acme.digicert.com/v2/acme/challenge/xxx
      Token:        xxx
      Type:         tls-alpn-01
      URL:          https://acme.digicert.com/v2/acme/challenge/xxx
    Identifier:     test2acme.cez.cz
    Initial State:  valid
    URL:            https://acme.digicert.com/v2/acme/authz/xxx
    Wildcard:       false
  Finalize URL:     https://acme.digicert.com/v2/acme/finalize/xxx
  State:            ready
  URL:              https://acme.digicert.com/v2/acme/order/xxx
Events:             <none>

In cert-manager logs we see:
I0223 09:35:37.464236 1 conditions.go:203] Setting lastTransitionTime for Certificate "testacme2-cez-cz" condition "Issuing" to 2024-02-23 09:35:37.464226319 +0000 UTC m=+88531.949846419
I0223 09:35:37.464303 1 conditions.go:203] Setting lastTransitionTime for Certificate "testacme2-cez-cz" condition "Ready" to 2024-02-23 09:35:37.464296227 +0000 UTC m=+88531.949916332
I0223 09:35:37.480151 1 controller.go:162] "re-queuing item due to optimistic locking on resource" logger="cert-manager.certificates-trigger" key="test-mb-certificates/testacme2-cez-cz" error="Operation cannot be fulfilled on certificates.cert-manager.io \"testacme2-cez-cz\": the object has been modified; please apply your changes to the latest version and try again"
I0223 09:35:37.480197 1 conditions.go:203] Setting lastTransitionTime for Certificate "testacme2-cez-cz" condition "Issuing" to 2024-02-23 09:35:37.480193216 +0000 UTC m=+88531.965813316
I0223 09:35:37.618654 1 conditions.go:263] Setting lastTransitionTime for CertificateRequest "testacme2-cez-cz-1" condition "Approved" to 2024-02-23 09:35:37.618645643 +0000 UTC m=+88532.104265747
I0223 09:35:37.669910 1 conditions.go:263] Setting lastTransitionTime for CertificateRequest "testacme2-cez-cz-1" condition "Ready" to 2024-02-23 09:35:37.669902695 +0000 UTC m=+88532.155522795

Logs after restarting cert-manager pod:
W0223 10:17:34.457007 1 client_config.go:618] Neither --kubeconfig nor --master was specified. Using the inClusterConfig. This might not work.
I0223 10:17:34.458761 1 controller.go:89] "enabled controllers: [certificaterequests-approver certificaterequests-issuer-acme certificaterequests-issuer-ca certificaterequests-issuer-selfsigned certificaterequests-issuer-vault certificaterequests-issuer-venafi certificates-issuing certificates-key-manager certificates-metrics certificates-readiness certificates-request-manager certificates-revision-manager certificates-trigger challenges clusterissuers ingress-shim issuers orders]" logger="cert-manager.controller"
I0223 10:17:34.460259 1 leaderelection.go:250] attempting to acquire leader lease kube-system/cert-manager-controller...
I0223 10:17:34.481297 1 leaderelection.go:260] successfully acquired lease kube-system/cert-manager-controller
I0223 10:17:34.509847 1 reflector.go:351] Caches populated for *v1.ClusterIssuer from k8s.io/client-go@v0.29.0/tools/cache/reflector.go:229
I0223 10:17:34.513741 1 reflector.go:351] Caches populated for *v1.Order from k8s.io/client-go@v0.29.0/tools/cache/reflector.go:229
I0223 10:17:34.513833 1 util.go:83] "owning resource not found in cache" logger="cert-manager.controller.certificaterequests-issuer-acme.handleOwnedResource" resource_name="testacme2-cez-cz-1-1786450120" resource_namespace="test-mb-certificates" resource_kind="Order" resource_version="v1" related_resource_namespace="test-mb-certificates" related_resource_name="testacme2-cez-cz-1" related_resource_kind="CertificateRequest"
I0223 10:17:34.521180 1 reflector.go:351] Caches populated for *v1.PartialObjectMetadata from k8s.io/client-go@v0.29.0/tools/cache/reflector.go:229
I0223 10:17:34.521209 1 reflector.go:351] Caches populated for *v1.Issuer from k8s.io/client-go@v0.29.0/tools/cache/reflector.go:229
I0223 10:17:34.521227 1 reflector.go:351] Caches populated for *v1.Challenge from k8s.io/client-go@v0.29.0/tools/cache/reflector.go:229
I0223 10:17:34.521484 1 reflector.go:351] Caches populated for *v1.Ingress from k8s.io/client-go@v0.29.0/tools/cache/reflector.go:229
I0223 10:17:34.522264 1 reflector.go:351] Caches populated for *v1.Certificate from k8s.io/client-go@v0.29.0/tools/cache/reflector.go:229
I0223 10:17:34.530084 1 reflector.go:351] Caches populated for *v1.PartialObjectMetadata from k8s.io/client-go@v0.29.0/tools/cache/reflector.go:229
I0223 10:17:34.541491 1 reflector.go:351] Caches populated for *v1.Secret from k8s.io/client-go@v0.29.0/tools/cache/reflector.go:229
I0223 10:17:34.640235 1 reflector.go:351] Caches populated for *v1.PartialObjectMetadata from k8s.io/client-go@v0.29.0/tools/cache/reflector.go:229
I0223 10:17:34.642436 1 reflector.go:351] Caches populated for *v1.CertificateRequest from k8s.io/client-go@v0.29.0/tools/cache/reflector.go:229
E0223 10:17:34.700207 1 controller.go:167] "re-queuing item due to error processing" err="ACME client for issuer not initialised/available" logger="cert-manager.orders" key="test-mb-certificates/testacme2-cez-cz-1-1786450120"
E0223 10:17:41.404339 1 sync.go:562] "failed to finalize Order resource due to bad request, marking Order as failed" err="404 urn:ietf:params:acme:error:malformed: order EDi0Zgwj5OJRiGbX2VHxrMzDczdALwI98H9t45BkFvc/AySKRJivvqILt0rRSdaZFWRCARNqujikHSNdYLExMCw has expired: 2024-02-23T02:45:39-07:00" logger="cert-manager.orders" resource_name="testacme2-cez-cz-1-1786450120" resource_namespace="test-mb-certificates" resource_kind="Order" resource_version="v1"
I0223 10:17:41.445757 1 conditions.go:192] Found status change for Certificate "testacme2-cez-cz" condition "Issuing": "True" -> "False"; setting lastTransitionTime to 2024-02-23 10:17:41.445743307 +0000 UTC m=+7.007096425

Please advise what could be wrong or where to look, we do not see any relevant errors anywhere, just nothing happens.

@bukovjanmic and @steache,
Are you using the RedHat cert-manager Operator or the cert-manager community maintained operator?
Based on the output in the PR description it looks like you're using the RedHat operator in which case please create a RedHat support request.
  Groups:
    system:serviceaccounts
    system:serviceaccounts:cert-manager-operator

It's difficult for us to help further because we don't have easy access to RedHat OpenShift clusters and we don't have a DigiCert account to test with.
Troubleshooting Problems with ACME / Let's Encrypt Certificates might help you pin point what is going wrong.
The logs you posted include the following error from the ACME service:

404 urn:ietf:params:acme:error:malformed: order EDi0Zgwj5OJRiGbX2VHxrMzDczdALwI98H9t45BkFvc/AySKRJivvqILt0rRSdaZFWRCARNqujikHSNdYLExMCw has expired: 2024-02-23T02:45:39-07:00

But I can't tell if that's because you restarted the Pod much later.
Please seek help from RedHat if you're using their operator and let us know if your investigations suggest there's a bug in cert-manager its self.

We are using the latest Community operator at the moment, and testing against Digicert test account (the one that is free and only issues 3 day test certificates).
However, after some more analysis, it seems to be some issue with ACME communicating with Digicert.
By trial and error, we observe that:

if we try to issue a certificate against a domain that we already tried on Digicert (no matter on which cluster and no matter if the ACME process finished), nothing happens, cert-manager is seemingly stuck (like I describe in this ticket). The same happens on certificate renewal after 3 days, no Challenge object is ever created and the certificate is not renewed.
if we try to issue a certificate against a domain that we never tried (e.g. arbitrary domain), the Challenge object is created and everything works normally (the ACME process may not conclude, but the Challenge object is there)
if we try to issue a certificate against a domain that we already tried, even on a different cluster, the process is stuck again

All our test clusters use the same Digicert testing account. We used cert-manager 12.1 where it worked and it still works on production. It only happens once we upgraded the cert-manager operator on our test environments.
We also tried to switch to Red Hat supported operator, but the results are the same.
Our wild guess that if a certain domain was already tried on Digicert, cert-manager receives some response from Digicert ACME that is not handled correctly and becomes stuck. There are no logs whatsoever, just nothing happens.
We would like to help debug this, if you could advise us how to trace ACME communication or if there is a way to dump ACME protocol communication, we post it here or analyze this.
Once the Challenge object is created, everything seems to work correctly from that point, e.g. challenge pod is created, traffic is routed, etc. The problem lies somewhere between initial ACME handshake and Challenge object creation,

The expiration message:

404 urn:ietf:params:acme:error:malformed: order EDi0Zgwj5OJRiGbX2VHxrMzDczdALwI98H9t45BkFvc/AySKRJivvqILt0rRSdaZFWRCARNqujikHSNdYLExMCw has expired: 2024-02-23T02:45:39-07:00

happens if we leave the Order in the stuck state for a day and then restart the cert-manager pod. It tries to reconcile, but the order is already expired, which is true.

@bukovjanmic you can increase the logging verbosity of the cert-manager controller by editing the cert-manager Deployment, which may log extra details about the interactions with the ACME service.
You could read the comments on these two Digicert issues and consider whether you might be encountering the same issue:

https://github.com/cert-manager/cert-manager/issues/6107
https://github.com/cert-manager/cert-manager/issues/4214

You could search to see if there are any issues with the library cert-manager uses https://pkg.go.dev/golang.org/x/crypto/acme#Client and the Digicert ACME service.

We increased the logging level to max, I attach complete log dump. Freshly created certificate, what we observe:

Order (testacme-cez-cz-1-3109166385) is correctly created
Challenge is not created, but this seems to be intentional ("Authorization already valid, not creating Challenge resource")
Order is stuck in Ready state
We see message Finalizing order, but we are not sure what is cert-manager waiting for, as no Challenge is created.
Cert-manager is in this state forever, until restarted, after which it either waits forever again or outputs the expiration message

apiVersion: acme.cert-manager.io/v1
kind: Order
metadata:
  annotations:
    cert-manager.io/certificate-name: testacme-cez-cz
    cert-manager.io/certificate-revision: '1'
    cert-manager.io/private-key-secret-name: testacme-cez-cz-jlk2k
  resourceVersion: '1109085968'
  name: testacme-cez-cz-1-3109166385
  namespace: test-mb-certificates
  ownerReferences:
    - apiVersion: cert-manager.io/v1
      blockOwnerDeletion: true
      controller: true
      kind: CertificateRequest
      name: testacme-cez-cz-1
      uid: 7da268d5-594b-498f-bd6a-22e314e6e15d
spec:
  commonName: testacme.cez.cz
  dnsNames:
    - testacme.cez.cz
    - test2acme.cez.cz
  issuerRef:
    name: digicert
  request: LS0tLS1CRU---redacted---LS0tLQo=
status:
  authorizations:
    - challenges:
        - token: V5Nkh---redacted---RfTfj
          type: http-01
          url: 'https://acme.digicert.com/v2/acme/challenge/EDi0Z---redacted---loa2A'
        - token: MCjhp---redacted---VxajD
          type: dns-01
          url: 'https://acme.digicert.com/v2/acme/challenge/EDi0Z---redacted---d8Mgc'
        - token: _NU-Q---redacted---HcxKDX
          type: tls-alpn-01
          url: 'https://acme.digicert.com/v2/acme/challenge/EDi0Z---redacted---Yeolhs'
      identifier: test2acme.cez.cz
      initialState: valid
      url: 'https://acme.digicert.com/v2/acme/authz/EDi0Z---redacted---9U5I2'
      wildcard: false
    - challenges:
        - token: Xy6X7---redacted---laY2T
          type: http-01
          url: 'https://acme.digicert.com/v2/acme/challenge/EDi0Z---redacted---BMRgv_'
        - token: 46VOf---redacted---qEWQ-
          type: dns-01
          url: 'https://acme.digicert.com/v2/acme/challenge/EDi0Z---redacted---_DZtD'
        - token: Dre_2---redacted---UsREtG
          type: tls-alpn-01
          url: 'https://acme.digicert.com/v2/acme/challenge/EDi0Z---redacted---H926U'
      identifier: testacme.cez.cz
      initialState: valid
      url: 'https://acme.digicert.com/v2/acme/authz/EDi0Z---redacted---WBu88'
      wildcard: false
  finalizeURL: 'https://acme.digicert.com/v2/acme/finalize/EDi0Z---redacted---Vq1i68'
  state: ready
  url: 'https://acme.digicert.com/v2/acme/order/EDi0Z---redacted---Vq1i68'

In logs, we also see:
I0308 09:00:46.463032       1 readiness_controller.go:191] "cert-manager/certificates-readiness: updating status fields" key="test-mb-certificates/testacme-cez-cz" notAfter="<panic: runtime error: invalid memory address or nil pointer dereference>" notBefore="<panic: runtime error: invalid memory address or nil pointer dereference>" renewalTime="<panic: runtime error: invalid memory address or nil pointer dereference>"
But that is possibly not the cause.
cert-manager-log.txt

We just faced the same issue:

I1016 09:37:11.439826       1 readiness_controller.go:191] "updating status fields" logger="cert-manager.controller" key="REDACTED/tls-certificate" notAfter="<panic: runtime error: invalid memory address or nil pointer dereference>" notBefore="<panic: runtime error: invalid memory address or nil pointer dereference>" renewalTime="<panic: runtime error: invalid memory address or nil pointer dereference>"

Running v1.15.3


Add continuous integration support

I didn't want to bother with an npm package.json or a grunt Gruntfile, so I made the script use a standard Travis VM and have it install npm and the required packages.

Looks good!


Update GreetingApp.java

Pull Request Type
What kind of change does this PR introduce?
[X ] Solved an issue/task
[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:
What is the current behavior?
Did not have logic to the code.
Issue Number: [#1516]
What is the new behavior?
Added basic logic to greet.
Other information

Merged

This is an automated message from Fork, Commit, Merge [BOT].

Thank you for your contribution! Your pull request has been merged. The files have been reset for the next contributor.
What's next?
If you're looking for more ways to contribute, I invite you to check out our forkcommitmerge.io website repository. The repository contain real issues that you can help to resolve or create some of your own if you see any bugs or want to add new features to the site, etc. You can also check out the Influences section in the README to find more projects similar to this one.
Also please leave a star to this project if you feel it helped you, i would really appreciate it.
I look forward to seeing your contributions!


Use wasi-http::Error in the wasi-http implementation

Currently any error in WasiHttpView::send_request will result in a trap instead of an error being returned back from the call to outgoing_handler::handle. This moves a large amount of the Result types in the implementation from anyhow::Error to types::Error. HostFutureIncomingResponse now contains a anyhow::Result<Result<IncomingResponseInternal, types::Error>> to keep track of both trappable errors and errors that will be returned to the caller.

Just needs a conflict resolved, then I'll stick it in the queue


typeof x now has a string literal union type

typeof x now has the string literal type 'string' | 'number' | 'boolean' | 'symbol' | 'undefined' | 'object' | 'function'. This will prevent typos and misunderstandings of typeof (eg typeof a === "array" or typeof o === "null"). And once #13789 is fixed, it will also provide completions.
For implementations that disobey the advice of the standard, it is easy to work around the type, although narrowing no longer works:
if (typeof x === "ActiveXObject" as string) {
  // no narrowing here
} else {
  // or here
}

Fixes #9506
Fixes #13771 (by making the incorrect narrowing an error)

@mhegazy Hey, got linked to this from the interwebs. Was going to adopt TS in SkateJS but it looks like you're making a breaking change as part of a patch milestone?

Can you elaborate on how SkateJS would be broken by this change?

2.2.0 is 2.2 RC; 2.2.1 is the release version of 2.2.

Can you elaborate on how SkateJS would be broken by this change?

We're not using it yet, but just breaking Skate doesn't concern me. Possibly breaking every consumer on a minor version does. I could be wrong, but this appears to be a change between the 2.1.x stable, minor range to the 2.2.x stable, minor range, correct? I could have easily missed something here.

2.2.0 is 2.2 RC; 2.2.1 is the release version of 2.2.

I apologise for my ignorance, I just couldn't infer that 2.2.1 was the stable after the 2.2 rc. Thanks for clarifying :)

I see, thanks for the explanation.
We make all changes that could result in an error, if previously was not, as "breaking" changes. We promise no breaking changes in revisions, e.g. 2.2.1 -> 2.2.2. but not in minor version upgrades e.g. 2.1 -> 2.2. We recommend that you fix your package.json to major.moinor of TypeScript. Please see https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes for the full list of breaking changes in the the past.
This change makes the type of typeof expressions to be 'string' | 'number' | 'boolean' | 'symbol' | 'undefined' | 'object' | 'function', which should cover all values you would get from one of the popular JS engines. The reason it is marked as breaking, is per the ES spec, an engine could generate a different value, so this is a "breaking change" if you happen to be running against an engine (that is not v8, chackra, spidermoneky, or Core).

What the reasoning behind not following semver? Npm docs recommend that modules follow server and will automatically allow minor bumps in a module by default. I'm concerned that by not following this convention will create unnecessary friction for TypeScript consumers who will by default be opted in to having their builds broken whenever typescript releases a minor version.

@BenSayers @treshugart the official semver issue is at #14116. You can read some of our reasoning and continue the discussion there.


Cam Controller Free Movement

Adds a flag that modifies mouse command input (seems to be predicted automatically) to allow 360 degree rotation.
An additional input which zeroes out the roll has been created for use with this feature.

Example Video
E2 used in video

These hooks shouldn't be added until the user is using a pod controller. Can we change that?
Also the math can be more accurate and optimized. I'll give code for that once I test it.

Here's the optimized code. From my tests, it gives the same result, but I can guarantee that it's much more efficient than using all those rotatearoundaxis
hook.Add("InputMouseApply", "wire_camera_controller_input_unlock", function(cmd, x, y, ang)
	if not enabled then return false end
	if not FreeMove then return false end
	if not IsValid( self ) then enabled = false return false end
	-- feels correct, might not be, but raw values were definitely too fast
	local smooth = mouse_sensitvity:GetFloat() * FrameTime()
	local matrix = Matrix()
	matrix:SetAngles( ang )
	-- could make this a number instead
	if unroll then
		local parent, hasParent = GetParent()
		if hasParent then
			local rolldiff = math.deg( math.asin( parent:GetUp():Dot( matrix:GetRight() ) ) )
			matrix:Rotate( Angle( y * smooth, -x * smooth, rolldiff * smooth ) )
		else
			matrix:Rotate( Angle( y * smooth, -x * smooth, -ang.r * smooth ) )
		end
	else
		matrix:Rotate( Angle( y * smooth, -x * smooth, 0 ) )
	end
	cmd:SetViewAngles( matrix:GetAngles() )
	return true
end)

If something doesn't feel right with this change, lemme know and I can fix it

Also I just realized that your if hasParent then branch will only work if the camera's forward is aligned with the parent's forward.

I think this might be right
hook.Add("InputMouseApply", "wire_camera_controller_input_unlock", function(cmd, x, y, ang)
	if not enabled then return false end
	if not FreeMove then return false end
	if not IsValid( self ) then enabled = false return false end
	-- feels correct, might not be, but raw values were definitely too fast
	local smooth = mouse_sensitvity:GetFloat() * FrameTime()
	local matrix = Matrix()
	matrix:SetAngles( ang )
	-- could make this a number instead
	if unroll then
		local parent, hasParent = GetParent()
		if hasParent then
			local parentMatrix = Matrix()
			parentMatrix:SetAngles( parent:GetAngles() )
			local diffMatrix = matrix:GetInverseTR() * parentMatrix
			matrix:Rotate( Angle( y * smooth, -x * smooth, diffMatrix:GetAngles().r * smooth ) )
		else
			matrix:Rotate( Angle( y * smooth, -x * smooth, -ang.r * smooth ) )
		end
	else
		matrix:Rotate( Angle( y * smooth, -x * smooth, 0 ) )
	end
	cmd:SetViewAngles( matrix:GetAngles() )
	return true
end)

Feels good, and looks a whole lot cleaner, thanks.
There is one small issue but it might be with my test E2, as the problem is amplified when the parent is rotating slower.
With UnRoll 1, rotating the camera too far past the parent's angle now results in this.
I tested the original code and it doesn't do this, but it does experiences issues of not maintaining the proper angle, so even with the shaking yours is still better.

Please add a comment about the "UnRoll" wire input to the C menu checkbox description. Something like, "The input UnRoll is only used if this option is enabled" or similar.

Ye I'll look at the roll calculation again later.

I think it's because when their forward vectors oppose each other, the roll gets inverted. I can make a simple hack to fix that.

This seems to do the trick
hook.Add("InputMouseApply", "wire_camera_controller_input_unlock", function(cmd, x, y, ang)
	if not enabled then return false end
	if not FreeMove then return false end
	if not IsValid( self ) then enabled = false return false end
	-- feels correct, might not be, but raw values were definitely too fast
	local smooth = mouse_sensitvity:GetFloat() * FrameTime()
	local matrix = Matrix()
	matrix:SetAngles( ang )
	-- could make this a number instead
	if unroll then
		local parent, hasParent = GetParent()
		if hasParent then
			local parentMatrix = Matrix()
			parentMatrix:SetAngles( parent:GetAngles() )
			local diffAngles = (matrix:GetInverseTR() * parentMatrix):GetAngles()
			if math.abs(diffAngles.y) > 90 then diffAngles.r = -diffAngles.r end
			matrix:Rotate( Angle( y * smooth, -x * smooth, diffAngles.r * smooth ) )
		else
			matrix:Rotate( Angle( y * smooth, -x * smooth, -ang.r * smooth ) )
		end
	else
		matrix:Rotate( Angle( y * smooth, -x * smooth, 0 ) )
	end
	cmd:SetViewAngles( matrix:GetAngles() )
	return true
end)

You'll still get gimble lock when the camera pitch goes 90 degrees with the parent's pitch, but that's normal since roll is undefined at that point.

Nicely done.
And wow, that's the second typo I've made in as many commit descriptions.

Yeah good catch. I just wrongfully assumed the hook required false for no change.


[FEATURE] Set up sqlite to store aich return

Set up sqlite to store aich return

It takes 4 hours.
done


DEPRECATION: A property of <xamoom-customer@view:-outlet::ember1023> was modified inside the didInsertElement hook.

DEPRECATION: A property of <xamoom-customer@view:-outlet::ember1023> was modified inside the didInsertElement hook. You should never change properties on components, services or models during didInsertElement because it causes significant performance degradation. [deprecation id: ember-views.dispatching-modify-property]
at HANDLERS.(anonymous function) (http://localhost:4200/assets/vendor.js:16463:7)
at raiseOnDeprecation (http://localhost:4200/assets/vendor.js:16371:12)
at HANDLERS.(anonymous function) (http://localhost:4200/assets/vendor.js:16463:7)
at invoke (http://localhost:4200/assets/vendor.js:16479:7)
at deprecate (http://localhost:4200/assets/vendor.js:16432:32)
at Object.deprecate (http://localhost:4200/assets/vendor.js:26471:37)
at exports.default._emberMetalMixin.Mixin.create._Mixin$create.scheduleRevalidate (http://localhost:4200/assets/vendor.js:53728:22)
at http://localhost:4200/assets/vendor.js:23984:32
at Object.BasicStream.notifySubscribers (http://localhost:4200/assets/vendor.js:32379:11)
DEBUG:
Ember             : 2.5.1
Ember Data    : 2.5.2
jQuery             : 2.2.3

+1


can't do sharepoint workflow, webpart and page library

Target SharePoint environment
SharePoint Online
What SharePoint development model, framework, SDK or API is this about?
Site designs & site scripts
Developer environment
Windows
What browser(s) / client(s) have you tested

[X] 💥 Internet Explorer
[X] 💥 Microsoft Edge
[X] 💥 Google Chrome
[ ] 💥 FireFox
[ ] 💥 Safari
[ ] mobile (iOS/iPadOS)
[ ] mobile (Android)
[ ] not applicable
[ ] other (enter in the "Additional environment details" area below)

Additional environment details

browser version
SPFx version
Node.js version
etc

Describe the bug / error

Steps to reproduce
1, sign to microsoft 365
2, at site page, right click, can't do the workflow.
3, also can't do webparts, page library
Expected behavior
would like to do workflow, webparts, page library, any other sharepoint design work.

? any advise??


Generate correlation ID for a network's execution.

It would be nice to have a unique ID represent the execution of a network from start to finish.  An example purpose for this ID would be to correlate log entries.

This will be provided via the scope feature in #356

Scopes are in released NoFlo, so for correlation IDs one just needs to send the initial packets (from outside, from a generator) with a scope set.


fix: Fix dapi the lost of block height

This feature should undergo more verification and needs to be modified later.


Why do javadoc tasks of depending projects depend on each other?

Given this simple java multi-module project: https://github.com/larsgrefer/gradle-javadoc-example
When executing ./gradlew b:javadoc --console=plain I can see that the task a:javadoc is executed, too. Why is this so?
b:javadoc seems to have no inputs which are generated by a:javadoc

Unfortunately I've been unable to work out why this is needed, but in case it helps you or someone else;
The dependency is created between the two tasks here. The javadoc tasks are configured to depend on the javadoc tasks of any project dependencies.

This seems to have been there since the beginning of time. I don't see why it's necessary either. You could look into the git history or just remove it and see if any tests break. A PR would be welcome.

I've had a look at the git history, but that didn't help.
I'll provide a PR which removes this.

@oehme Seems like all tests are running fine


Add UniProt vocabularies

These 3 are all added to bioregistry in https://github.com/biopragmatics/bioregistry/commit/75ffc9f4cb340a2a4cb8305b4f7940c923ff3c0f


Consider adding support for #[serde(default = $expr)]

There is a bit of a dance that happens when deserializing a struct, and one of the fields is missing. serde_codegen effectively does:

Was the field attributed with #[serde(default)]? If so, set the value Default::default(), assuming that the field type actually implements Default.
Otherwise, call the Deserializer's missing_field() method. If the format has some built-in support for a value for a missing field, such as JSON considering a missing value as a null value, try to deserialize from that value, or return an error.

This unfortunately means that as a consumer, you may have to newtype yourself an implementation of Default. Instead, it might be better if we optionally allowed for #[serde(default = $expr)], where if the value is not present, we evaluate some expression. This would cut down on some of the boilerplate necessary for using serde_codegen.
Open question: If we do implement this, is this expression being evaluated in the same scope as Deserialize::deserialize? On one level it'd be potentially interesting that it'd be able to access one of the other values to implement itself, but I consider the serde_codegen generated bodies to not be a stable interface. So I'm leaning towards us putting the $expr into a sub-function to keep it from accessing the internal deserialization state.
cc #198, which has a similar idea for specifying alternative serializers/deserializers.

This was implemented in #238!


Keep permanode support as it is?

Do we want permanode support in the client like it is now or should we change/remove it? Currently it's a bit messy, one can add a permanode with with_permanode() and in get_request() have a prefer_permanode bool parameter we hardcoded for each endpoint, which will then use a permanode first if available and otherwise a normal node.
Nodeinfo doesn't work because the response is different, posting a block and getting tips will never be possible, but for users it's not clear what is supported or not.
Permanodes also have other API endpoints one can call with call_plugin_route(), but currently only if one would provide a permanode as normal node, because there prefer_permanode is set to false

Closed by https://github.com/iotaledger/iota-sdk/pull/1980


[core] upgrade dependencies with esm support

is-plain-object (https://github.com/jonschlinkert/is-plain-object/pull/16)
normalize-scroll-left (https://github.com/alitaheri/normalize-scroll-left/pull/3)
convert-css-length (https://github.com/KyleAMathews/convert-css-length/pull/1)

parse-unit of convert-css-length is still pending (https://github.com/mattdesl/parse-unit/pull/1).

[X] I have followed (at least) the PR section of the contributing guide.

Wow


Update Cake.Coveralls reference from 1.0.0 to 1.0.1

This pull request was manually created because Cake.AddinDiscoverer triggered AbuseException before it was able to submit this PR.
Resolves #827

Rebased and merged here: https://github.com/cake-contrib/Cake.Recipe/commit/3842b2b7f5d2176130e2814eccc511f14e1e2edf


API mismatch with reality?

Version in use
I'm using version 0.7.4 with the current version of Azure DevOps (which as far as I can tell is still the same API version 7.1.
Case 1
When using the pipeline_client to get a current pipeline I'm getting errors of the sort:
context: Full(Custom { kind: DataConversion, error: Error("missing field ``id``", line: 1, column: 455) }.
However looking inside the response an "id" field is present. So the error message seems wrong
Case 2
When using the runs_client on the same pipeline I'm getting this error:
context: Full(Custom { kind: DataConversion, error: Error("missing field ``finishedDate``", line: 1, column: 1723) }
finishedDateis indeed not part of the response. However this run isn't finished so I wouldn't expect it? I'm guessing this value should be optional and isn't.
Case 3
If I choose a run that has finished the response is ok.
Summary
I guess some of the API isn't covered correctly. This is especially an issue since I need unfinished runs from the API.

I think Case #2 could be solved by replacing this diff in src/pipelines/models.rs:436
-    #[serde(rename = "finishedDate", with = "crate::date_time::rfc3339")]
-    pub finished_date: time::OffsetDateTime,
+    #[serde(rename = "finishedDate", with = "crate::date_time::rfc3339", skip_serializing_if = "Option::is_none")]
+    pub finished_date: Option<time::OffsetDateTime>,

However since this crate is auto-generated I won't add a PR.

I checked and the optionality of finishedDate is indeed not documented. Could this somehow be patched?

Looking at the API for the pipelines GET:
https://learn.microsoft.com/en-us/rest/api/azure/devops/pipelines/pipelines/get?view=azure-devops-rest-7.1
It seems to be all there however I noticed the fields in the API definition are:

_links
configuration
folder
id
name
revision
url

However the response I get is:

_links
configuration
url
id
revision
name
folder

So I'm guessing we're looking for folder, find folder at the end. But then skip everything in between, and the next field id can't be found.
I guess the fix would be not to care for the order here. Is that possible?

Thanks very much for the detailed report!
For Case 2, as you suggest the issue is that the existing code treats Run::finishedDate as a required field.  This was actually due to configuration in my spec patcher to try and eliminate some of the Option wrappers in returned structs.  See here for more details. It had worked in my previous testing, but that was just because I hadn't tested with an InProgress run!
https://github.com/microsoft/azure-devops-rust-api/issues/6
I managed to repro the issue, and found that the result field is also missing when the status is InProgress, so have also made that optional.

For Case 1, the issue is not field ordering - the code is fine with the fields in any order.
Given the information that you have provided, I think the issue is with an id field elsewhere in the nested structs.  Looking at the definitions, I see that the configuration field is of type PipelineConfiguration, and that has a repository field of type Repository that has id and type fields which are currently required.  I am guessing that in your scenario the id must be missing from this value (possibly the type too?).  It would be good if you could confirm, if you can still repro and look at the data.
I'll make a speculative fix here to make both of these fields optional, which should hopefully fix your scenario.

For case 1 I can check on Monday, I'm not sure what the output was, I just didn't want to post the full response here, but I could add a redacted response maybe.

Yes - don't post any of your data here.
When you get the error, you should get the response data on the console.  It will be a long single line.  The error message gives you a location where the issue is, e.g.  Error("missing field id", line: 1, column: 455).  You should be able to copy/paste the data into an editor and look at that column position.  It should be at the end of the object that is missing the id field.  You might be able to figure out which structure field it is (in particular, whether it is the repository field).

I've just published a new release 0.7.5 that I think should fix both of your issues (assuming that my speculative fix works).
Please try it out and let me know.

@johnbatty Hi, I checked the response and the speculative fix or the pipelines indeed worked, the repository field is repository: Repository { id: None, type_: Some("gitHubEnterprise") }, I'm guessing this only happens with non-azure repos or something other that's unusual.
Getting an inProgress run (as well as a finished run) works, too.
Thank you!

Great news.  I suspected that the Repository might look like that, and would explain why I hadn't seen it (I've only tested with pipelines that refer to ADO repos).
Please continue to raise any other issues you find.


login parameter ingestion fix

an empty set would get passed into the Sync-Only function if the user supplied a value for the login parameter

Type of Change

[x] Bug fix (non-breaking change, fixes #2176 )
[ ] New feature (non-breaking change, adds functionality)
[ ] Breaking change (effects multiple commands or functionality)
[ ] Ran manual Pester test and has passed (`.\tests\manual.pester.ps1)
[ ] Adding code coverage to existing functionality
[ ] Pester test is included
[ ] Nunit test is included
[ ] Documentation
[ ] Build system

Purpose

Fixes the -Login parameter in Sync-DbaSqlLoginPermission

heyyy fantastic! thank you. will merge once tests pass. and I'll likely add a regression test.

awesome, tests pass! thank you very much, @crony1 🌮 👍

woo hoo!

should be in the gallery shortly :)


Investigate and add ability to verify downloaded files with hashes (md5 likely)

Apparently the hashes are available for most files if you change the extension of the resolved filename e.g. file-url.exe?code to file-url.exe.xml?code. So in the future I'll need to get those files as well and implement md5 validation for chunks

Fixed with 5d733b9ed81d6ccc17992d9c09410125529780f7


Bug in UI when trying to forward multiple ports

VSCode Version:

Version: 1.51.0-insider (user setup)
Commit: 16f4a29aa0ac05d3cba222b1f347b7404626c680
Date: 2020-10-26T05:35:22.508Z
Electron: 9.3.2
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.20201

OS Version: Windows 10 Home Insiders

Steps to Reproduce:

When you try to forward multiple ports, the UI behaves strangely and am not able to add a port to the existing list of forwards.

Have not faced this issue again since yesterday's insiders release. If I continue to face this, will report back.

Thanks!


Replace internal abstract class BaseView to internal trait

I am not sure if a ViewInterface is enough. Would love to have a ResponseInterface of some type as the base, as a Controller can have multiple types of Responses. A ViewResponse, A RedirectResponse, a JsonResponse, etc.

I am not sure if a ViewInterface is enough. Would love to have a ResponseInterface of some type as the base, as a Controller can have multiple types of Responses. A ViewResponse, A RedirectResponse, a JsonResponse, etc.

For responses need use https://github.com/yiisoft/data-response.


Add csdp to the Coq Platform

The psatz tactic uses the external tool csdp.
To make it convenient for users of any platform to call psatz, I propose that csdp is included in the Coq Platform. Debian and Ubuntu users can already install it as the package coinor-csdp.

@palmskog : there is a homebrew package for csdp, but neither a macports nor a cygwin package. So the easiest path might be to create an opam "from sources" package for csdp, but as far as I know coinor, this might get a bit involved. Is there someone who might be able to help with this?
In general I have some interest in a reasonable install method for coinor, since I also sometimes want it for other things, but I am not sure I have time for this.
I am not in favor of including it if we can't support it on half of the Macs and on Windows. Also I am not sure about the other Linux distros.

Unfortunately I don't know anyone with the right expertise who could help out with packaging this. Could we maybe add some kind of "help wanted" tag here to the issue and postpone inclusion until we find more help? This is not a critical package for me, but several people have wondered about using psatz more easily.

Yes - we have a help wanted label.
As I said eventually I will likely do it if no one else does it, just because for many LP problems one needs a second or third opinion (see e.g. https://gist.github.com/MSoegtropIMC/2d4fdfe6b1e3e3955c63084523db3ca7) or a formally verified solver ... But it might take a while.

I Cc @proux01 in case he'd have some experience running csdp on Windows…
(indeed, our ValidSDP library relies on his osdp libary which is an ocaml library providing a unified library for several SDP solvers, including but not limited to csdp)

Also, see the conf-csdp opam package (which is one of the dependencies of osdp)

The opam package has just:
depexts: [
  ["coinor-csdp"] {os-family = "debian"}
  ["csdp"] {os-distribution = "centos"}
]

which is quite a bit below the range of platforms we support and at least on Windows and MacPorts it won't be just adding depext lines.

Indeed, the conf-csdp package only checks that csdp is installed but doesn't actually package it (which is not trivial since its C code depends on blas/lapack and fortran). And indeed, the depext packages availability seems rather limited.

I postponed this package inclusion to the next release which will likely happen in November (for Coq 8.14)

As per discussion on Zulip, inclusion of csdp in the platform has been postoned further, possibly indefinitely.

@palmskog : as I said eventually I will likely do it, but right now there are too many things which give a higher benefit for less work (coq-hammer e.g.).

I agree about coq-hammer, this was mainly just to inform that people can't start to rely on csdp in 2021.11.

Do you see a big benefit in it? I tried it a few times and it usually didn't do what I want, so I tend to use either lra or coq-interval or a combination of both. This works well in automation, because it is pretty clear what goals both can solve and what not. Is there some space between the two I didn't happen to run into as yet?
My interest in CSDP is more in CSDP itself, so psatz would be a side effect.

One of the main benefits of CSDP is that we could potentially add Validsdp to the platform once we have it (assuming @proux01 and @erikmd are interested in this).

Indeed Validsdp is more what I am interested in. I have a lot of issues with LP solvers producing garbage results.

Triage note: this is still complicated to support on all platforms - help welcome!

A student advised by @erikmd recently added a csdp package to the OCaml OPAM repo. This works on various Linux and mac distribs but still requires testing/adaptation for Windows: https://github.com/ocaml/opam-repository/pull/25721

@proux01 : thanks for the note - i will look into it again.

Yes @MSoegtropIMC: for the record, the approach followed by my student was exactly your initial suggestion:

the easiest path might be to create an opam "from sources" package for csdp

→ https://opam.ocaml.org/packages/csdp/
The CI logs are not available anymore, but as far as I can tell, all Linux distributions tested in opam CI (except oraclelinux) were fine (e.g., debian + ubuntu + fedora + centos + opensuse + arch) as well as freebsd + macos-homebrew.
Even if csdp was already packaged in just a few distros of these.
But testing/adapting the package for windows-cygwin is still missing.

@erikmd : thanks! I had a quick look at the opam package - it looks doable on cygwin.
Is there a good reason for using sed instead of patch, say many lines matching each sed patch?

Not real reason, it was easy to use sed, but if patch is preferable for any reason, we can certainly change.

The various sed lines just aim to:

fix an upstream bug by adding a missing line in the sources (can be easily replaced with a patch)
ensure the Makefile is properly configured for various os and distribution (the required Makefile tweaks might be doable with patch, but much more tricky I guess, as there are multiple cases…)

Yes I am aware of this feature of patch.
But again, I am not sure it is adapted for the second kind of substitution I was talking about:

ensure the Makefile is properly configured for various os and distributions (the required Makefile tweaks might be doable with patch, but much more tricky I guess, as there are multiple cases…)

because it is conditional patching, i.e., only for some os / distributions (which does not seem to be possible with opam)
and the hypothesis whether "the [sed] does not apply any more" is very unlikely, because csdp development seems to have stalled, so the current version is the reference one AFAICT

The OPAM build rule currently calls sed, it could as well call patch (with the same conditions)

OK! I better understand your idea.
@MSoegtropIMC is it "required" from your viewpoint to do this "refactoring"?
AFAIAC I won't have the time to do this in the upcoming weeks.

Indeed the idea is to have 4 patch files - one for each OS. This is for sure more readable and more error resilient.
As a compromise let's say it shall be changed in case there ever is a new version.
As Coq Platform maintainer I am having my share of updating other peoples opam packages, so I guess I am more picky about the maintainability of opam packages than others.

Maybe I change it in case I need to change something for cygwin.

@proux01 : we are currently discussing this in the board. First sorry for the long delays - it is still technically difficult to make a reliable multi-platform build of CSDP. We wonder if this is still needed by non linear arithmetic tactics, or if this request is meanwhile outdated.

CC Frérdéric Besson @fajb

Since the request is > 4 years old it just makes sense to ask the experts and re-assess this before making a decision.
The dependency of VaildSDP is noted!
An important question is if psatz still depends on it (psatz is mentioned in the 8.20 ref manual) and if psatz is still a recommended / actively maintained tactic or if there are plans to deprecate it (I don't suggest this in any way - I just ask what the plans are so that we have all information on the table).
Oh, I just saw that the 8.20 ref manual mentions in the header of https://coq.inria.fr/doc/V8.20.0/refman/addendum/micromega.html that psatz depends on csdp, so the first part of the above question is answered (this is not mentioned in the section of psatz as such - it probably should).
So only the second part of the question remains.

For the second part: we still have in the test-suite examples that can be solved only by psatz. So I'd say it still has some interest.

OK, thanks.
I had a look at the csdp opam package - looks good to me since it builds from sources. For not so frequently used Linux packages I am not a big fan of system supplied packages, since the versions one gets various too much.


Support (visual only) mapmode 'x'

Following:
wk.register({ i = { h = {':<C-U>lua require"gitsigns".select_hunk()<CR>', 'Git hunk'}}}, {mode = "x"})

results in:
WhichKey: Invalid mode "x" for buf 0

while the same with "v" as mode works as (almost) expected.

Should be fixed now. Thank you for the report!

Thanks for the quick fix, just tested it, it's working.