Inner exceptions on @property DocType

Using a property on classes makes debugging a nightmare, for example:
from elasticsearch_dsl import DocType, Search
class Foo(DocType):
    @property
    def bars(self):
        return Search().eecute() # with a filter in reality

foo = Foo()
foo.bars

This will raise AttributeError: 'Foo' object has no attribute 'bars'
The actual exception is KeyError: "There is no connection with alias 'default'."
  File /elasticsearch-dsl/elasticsearch_dsl/search.py", line 366, in execute
    es = connections.get_connection(self._using)
  File "/elasticsearch-dsl/elasticsearch_dsl/connections.py", line 53, in get_connection
    raise KeyError('There is no connection with alias %r.' % alias)

I think the except AttributeError clauses in AttrDict and ObjectBase should be removed, I don't see how they add anything.

Another problem with properties:
class Foo(DocType):
     _value = 'old'
     @property
     def value(self):
         if self._value is 'old':
             self._value = 'new'
         return self._value

Foo().value
>>> 'old'

They add cosistency - if I am accesing an attribute: result.title and the property doesn't exist, I expect an AttributeError, not a KeyError.
I can see the issues in the properties you wrote here, but I don't see the connection with AttrDict and ObjectBase, could you please elaborate where these are hurting you? Thanks

I agree on the consistency aspect, and would definitely expect an AttributeError on attribute access, I don't have a good answer there yet, maybe an AttrDictAttributeError which will keep the original exception.. I'm not sure if it's possible.
The problem is due to the nature of attrdicts having the tendancy to consider attribute failure as a missing attribute rather than an actual exception. This makes the first access of an attribute on an attrdict the initial error.
The places where this will bite you in the ass on a complicated model are plenty, a simple case:
from elasticsearch_dsl import DocType
class Product(DocType):
    pass

class Category(DocType):
    @property
    def products(self):
        return Product.all()

category = Category(name='laptop')
category.products

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/dan/env/local/lib/python2.7/site-packages/elasticsearch_dsl/document.py", line 166, in __getattr__
    return super(DocType, self).__getattr__(name)
  File "/home/dan/env/local/lib/python2.7/site-packages/elasticsearch_dsl/utils.py", line 374, in __getattr__
    return super(ObjectBase, self).__getattr__(name)
  File "/home/dan/env/local/lib/python2.7/site-packages/elasticsearch_dsl/utils.py", line 81, in __getattr__
    '%r object has no attribute %r' % (self.__class__.__name__, attr_name))
AttributeError: 'Category' object has no attribute 'products'

Category does have an attribute products, Product.all is missing - but the exception will make no mention of this. Consider a complex model with methods/attributes all depending on each other. The result is wasting time following the chain of events, which is what we have tracebacks for in the first place.

Oh, I see - the problem is that when your property raises an AttributeError then AttrDict.__getattr__ is called and it will raise it's own AttributeError not mentioning the original (because it cannot).
This is actually a known Python behavior (you might even call it a bug) that currently has no workaround. The consensus amongst python people is to just make sure your properties don't raise AttributeError - that's what's causing __getattr__ to be invoked.
Why this cannot be fixed is because there are legitimate use cases for this behavior - when raising AttributeError from a property should trigger a __getattr__ call - it's an option left there for the programmer. If you don't wish it it's recommended you catch AttributeError and raise a different error instead, that will be correctly propagated.
As far as I know none of the properties defined by this library can ever raise AttributeError unless something goes seriously wrong (people messing with our objects' internal states etc). If you find a place where it is not so we will definitely treat it as a bug and fix it asap.

I'm not talking about properties intentionally raising an AttributeError. I'm saying that there will be times when a simple typo bug will lead to an AttributeError being raised, which will be hidden because ObjectBase try: excepts: it away.
>>> from elasticsearch_dsl import DocType
>>>
>>> class RegularClass(object):
...     @property
...     def foo(self):
...         return self.typo
...
>>> RegularClass().foo
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in foo
AttributeError: 'RegularClass' object has no attribute 'typo'
>>>
>>> class DocTypeClass(DocType):
...     @property
...     def foo(self):
...         return self.typo
...
>>> DocTypeClass().foo
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/dan/env/local/lib/python2.7/site-packages/elasticsearch_dsl/document.py", line 166, in __getattr__
    return super(DocType, self).__getattr__(name)
  File "/home/dan/env/local/lib/python2.7/site-packages/elasticsearch_dsl/utils.py", line 374, in __getattr__
    return super(ObjectBase, self).__getattr__(name)
  File "/home/dan/env/local/lib/python2.7/site-packages/elasticsearch_dsl/utils.py", line 81, in __getattr__
    '%r object has no attribute %r' % (self.__class__.__name__, attr_name))
AttributeError: 'DocTypeClass' object has no attribute 'foo'

You'd expect an object in python to tell you that offending line is return self.typo not that the object has no attribute foo.

Just to be clear, ObjectBase does not try/except it away - it's python's object class that does this in it's __getattribute__ - when a class has __getattr__ defined, this is the behavior:
class A(object):
    @property
    def f(self):
        return self.g

    def __getattr__(self, name):
        raise AttributeError(name + '!!!')

print(A().f)

it is standard python behavior and that's why I am reluctant to "fix" it. The fix would also contain modifying the object's __getattribute__ instead of __getattr__ which is potentially dangerous and can have some performance implications. I will run some tests and see what the difference would be if it's worth it.

Switching over to __getattribute__ will make attribute access 3x slower as it currently is with __getattr__ if the attribute exists in the underlying dict and 2x slower if it doesn't. We are already much slower that raw attribute access so I'd hate to compound the issue.
I understand the frustration with misleading errors, I am just not sure it's worth the slowdown, especially when it's just an unfortunate feature of python and not behavior we are introducing.

I am sorry, my assumptions that it won't happen often has been shown as invalid. Thank you for raising this, I will fix this as part of #81


Locks down deps and lints package.json

Sorry about that! Didn't even notice the versions were locked down.

I think that's what package-lock.json is supposed to do, but I kinda don't trust anything anymore. =)
So I do them both now.

Oh, I have a vscode add which sorts JSON alphabetically by keys, so that's what's causing the other changes... sorry, i should turn that off.


[$1000] mWeb/Safari - Chat - Focus is lost and keyboard does not open when selecting ‘Edit comment’

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

Action Performed:

Open staging.new.expensify.com in Mobile Safari on iPhone
Login with any account
Go to any chat with existing messages or send new message
Long tap on message
Select 'Edit comment' in context menu

Expected Result:
Message in 'Edit' mode > Keyboard is open and focus on the edited message
Actual Result:
Focus is lost and keyboard does not open when selecting ‘Edit comment’
Workaround:
Unknown
Platforms:

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

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

Version Number: 1.3.55-3
Reproducible in staging?: Yes
Reproducible in production?: Yes
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://github.com/Expensify/App/assets/78819774/9e292965-b54e-46d5-938c-14a0b4e107bf
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/~019d806d4cf680deb9
Upwork Job ID:<PHONE_NUMBER>126630912
Last Price Increase: 2023-08-28

Different issue, but slightly related to https://github.com/Expensify/App/issues/24555 in that they are both unexpected behaviors when selecting Edit Comment in the mobile app.

Unable to repro in DEV
Is there any extra steps?

Proposal
Please re-state the problem that we are trying to solve in this issue.
After clicking Edit Comment, the text input box is not getting focussed, resulting in keyboard not opening automatically on mobile phones.
What is the root cause of that problem?
https://github.com/Expensify/App/blob/main/src/pages/home/report/ContextMenu/ContextMenuActions.js#L283
In the editAction function, we are not calling the focus method when closePopover is true. In all the other functions, ReportActionComposeFocusManager.focus(); is called in one way or the other, making sure the focus is correctly and manually set.
What changes do you think we should make in order to solve the problem?
We need to ensure the focus gets set on the correct text input. The ReportActionComposeFocusManager only handles focus on the default text input box for the main chat.
I would suggest creating a FocusManager that focuses on the newly created Edit Textbox and switches focus to it.
What alternative solutions did you explore? (Optional)
We can open the edit in its own page like 'reply in thread' functionality and set the focus to the default chat box using ReportActionComposeFocusManager, but that changes the UI and is not a bugfix.
PS: Seems like reply in thread is also not setting the focus correctly.

@swakeert Your RCA is missing an explanation of why this would only apply to Safari mWeb (if that is indeed the case!). I'm also curious if you're able to reproduce the issue on latest main?

@lanitochka17 are you still able to reproduce? We've reports that it's no longer reproducible.

this safari issue https://bugs.webkit.org/show_bug.cgi?id=195884

@pradeepmdk Are you able to reproduce the issue on latest main? You're welcome to raise a proposal to fix the issue if so!

yes, @jjcoffee is still an issue there. i will try  prepare the solution

I was still able to reproduce this on staging and prod. @pradeepmdk looking forward to your proposal!

@pradeepmdk how's it coming?
If we don't get any proposals soon, I'll ask our expert contributors to help out with this one.

@sakluger not yet. because they are allowing only user touch events based on their showing. We can't do anything here
We can check with expert contributors as well.

Waiting for proposals!
@swakeert are you interested in fleshing out your proposal with more details?

@jjcoffee I  found this https://github.com/Expensify/App/issues/10414

@jjcoffee I found this https://github.com/Expensify/App/issues/10414

Interesting, good find! I left a comment there asking if their PR will fix this issue. I'll put this one on hold while we wait for a response.

No response, asked again.

Parashat said we can leave this issue on hold for https://github.com/Expensify/App/issues/10414.

Still on hold for that other issue, which ended up getting delayed when an edge case was discovered that made the fix not work.

Still no updates on the hold issue.

Still on hold.

Still on hold for https://github.com/Expensify/App/issues/10414. I commented on that issue to see if we still planned to fix that one.

Still on hold for https://github.com/Expensify/App/issues/10414.

Adding to vip-vsb since this is chat-related funcationality.

Still on hold for https://github.com/Expensify/App/issues/10414

No updates on the hold issue.

Still on hold.

No update.

Still no updates on the hold issue.


did registry  has  api that only untag the image tag ?

same image id

two tags
delete

two tags both deleted in the end

ya, am looking at too...
so far, I go to the /var/lib/registry//_manifest/tags/ and run  rm -fvr

Hi, please see #2317 (comment). Closing this issue as it's a duplicate.


Replace codecov

Codecov is unstable (eg. https://github.com/riok/mapperly/actions/runs/6933245531/job/18859255434?pr=924). We should replace it with an alternative which supports visualising the code coverage, failing the PR if a given coverage falls below a given threshold or if the changes of the PR are not covered.

Upgraded to the action v4, lets see if this helps.


Call to undefined method upsert

Call to undefined method Illuminate\\Database\\Query\\Builder::upsert()
Laravel ^6.2

Hi, i have the same problem.
Call to undefined method Illuminate\Database\Query\Builder::upsert()
Laravel 7

@webds Please create a new issue.


How do I redeploy a new version of node-red ?

From your previous reply: "You are using a node that supported the old beta version of the Visual Recognition service. That version of the service has been deprecated. All new instances of the service make use of the new API. For that you will need to update to the latest versions of the nodes. To do this you will need to redeploy your instance of node-RED. You can do this by clicking on the git link associated with your instance.
The latest set of nodes, have a V3 Pink node for Visual Recognition which you will need to use. The palette also has a set of deprecated nodes, where you will find the old Blue node. It has been kept as although the beta service has been deprecated and new instances can't be instantiated, old ones had been working. Based on your description, I am guessing that the old beta service has been switched off. Once I have verified this I will be removing the deprecated node from the palette."
I redeployed, but it just deployed with my current code. How do I get it to deploy from my github within bluemix with the newest code?

This is not the right forum to ask questions on redeploying applications on Bluemix. Please use the developerworks forum for this question. To redeploy you need to be in jazz hub.


Chart v3.0.0-rc.6: Missing Gridline right side....

Expected Behavior

The last gridline is not drawn on the right for all charts. Can I correct this through settings or is it a mistake?
Current Behavior

Possible Solution

???
Steps to Reproduce

see: http://www.ipscon.com/test/testcase1.html
Environment

Chart.js version:  v3.0.0-rc.6
Browser name and version: any...
Link to your project:

Seems like a bugg that came in 3.0.0-rc, before that it was working fine (https://jsfiddle.net/Leelenaleee/mcpwfrxa/3/)

@LeeLenaleee your fiddle does not reproduce this

The padding is only reduced:

Probably related to autoSkip:

Missing also on the top (horizontal bar)

Perhaps this is related to how the right axis padding is computer? I guess we need to add 0.5 * lineWidth for the last vertical gridline

Perhaps this is related to how the right axis padding is computer? I guess we need to add 0.5 * lineWidth for the last vertical gridline

Negativ, do not work
{
    "top": 12,
    "right": 12,
    "bottom": 12,
    "left": 12
}
gridlineWidth: 0.8

{
    "top": 12,
    "right": 48,
    "bottom": 12,
    "left": 12
}
gridlineWidth: 0.8

Sorry, I should have been clearer. The axis itself has some padding in it, but right now it's only computed for the labels https://github.com/chartjs/Chart.js/blob/master/src/core/core.scale.js#L699-L700

@zibous can you try if #8748 would work for you?

Looks like that this fix do not work or do have do change something ??
Before Fix:

After Fix:

{
    "type": "bar",
    "data": {
        "datasets": [
            {
                "label": "Energieproduktion",
                "unit": "kWh",
                "minval": 0,
                "maxval": 0,
                "sumval": 0,
                "avgval": 0,
                "pointRadius": 0,
                "current": "57.0",
                "last_changed": "2021-03-30T05:33:03.175810+00:00",
                "mode": "history",
                "backgroundColor": "#fcec34",
                "data": [
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.274
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.266
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.372
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.72
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.765
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.892
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.604
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.993
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.858
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.417
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.1
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.129
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.288
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 1.356
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 2.617
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 2.927
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 2.458
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 2.73
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 2.046
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 1.479
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 1.343
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.204
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.117
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.099
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.203
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.283
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 2.796
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 2.69
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 2.336
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 2.583
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 2.043
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 1.443
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 1.283
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.198
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.096
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.057
                    }
                ]
            }
        ],
        "labels": []
    },
    "options": {
        "units": "",
        "hoverOffset": 8,
        "layout": {},
        "chartArea": {
            "backgroundColor": "transparent"
        },
        "hover": {
            "mode": "nearest",
            "intersect": true
        },
        "elements": {},
        "spanGaps": true,
        "plugins": {
            "title": {},
            "tooltip": {},
            "legend": {
                "display": false
            }
        },
        "animation": {},
        "onResize": null,
        "scales": {
            "x": {
                "axis": "x",
                "type": "time",
                "time": {
                    "unit": "hour",
                    "displayFormats": {
                        "day": "d.MM.yyyy",
                        "hour": "HH:mm",
                        "datetime": "MMM d, yyyy, h:mm:ss aaaa",
                        "millisecond": "h:mm:ss.SSS aaaa",
                        "second": "h:mm:ss aaaa",
                        "minute": "h:mm aaaa",
                        "week": "PP",
                        "month": "MMM yyyy",
                        "quarter": "qqq - yyyy",
                        "year": "yyyy"
                    },
                    "tooltipFormat": "d.MM.yyyy hh:mm",
                    "parser": false,
                    "round": false,
                    "isoWeekday": false,
                    "minUnit": "millisecond"
                },
                "alignToPixels": true,
                "stacked": true,
                "offset": true,
                "grid": {
                    "offset": true,
                    "display": true,
                    "drawBorder": true,
                    "drawOnChartArea": true,
                    "drawTicks": true,
                    "tickLength": 8,
                    "borderDash": [
                        1,
                        1
                    ],
                    "borderDashOffset": 0,
                    "borderColor": "#0288d1",
                    "borderWidth": 0.8800000000000001,
                    "color": "#b3e5fC"
                },
                "bounds": "data",
                "adapters": {},
                "ticks": {
                    "source": "auto",
                    "major": {
                        "enabled": false
                    },
                    "minRotation": 0,
                    "maxRotation": 50,
                    "mirror": false,
                    "textStrokeWidth": 0,
                    "textStrokeColor": "",
                    "padding": 3,
                    "display": true,
                    "autoSkip": true,
                    "autoSkipPadding": 3,
                    "labelOffset": 0,
                    "minor": {},
                    "align": "center",
                    "crossAlign": "near",
                    "color": "#e1e1e1"
                },
                "display": true,
                "reverse": false,
                "beginAtZero": false,
                "grace": 0,
                "title": {
                    "display": false,
                    "text": "",
                    "padding": {
                        "top": 4,
                        "bottom": 4
                    },
                    "color": "#e1e1e1"
                },
                "id": "x",
                "position": "bottom"
            },
            "y": {
                "axis": "y",
                "stacked": true,
                "type": "linear",
                "beginAtZero": true,
                "ticks": {
                    "minRotation": 0,
                    "maxRotation": 50,
                    "mirror": false,
                    "textStrokeWidth": 0,
                    "textStrokeColor": "",
                    "padding": 3,
                    "display": true,
                    "autoSkip": true,
                    "autoSkipPadding": 3,
                    "labelOffset": 0,
                    "minor": {},
                    "major": {},
                    "align": "center",
                    "crossAlign": "near",
                    "color": "#e1e1e1"
                },
                "display": true,
                "offset": false,
                "reverse": false,
                "bounds": "ticks",
                "grace": 0,
                "grid": {
                    "display": true,
                    "drawBorder": true,
                    "drawOnChartArea": true,
                    "drawTicks": true,
                    "tickLength": 8,
                    "offset": false,
                    "borderDash": [
                        1,
                        1
                    ],
                    "borderDashOffset": 0,
                    "borderColor": "#0288d1",
                    "borderWidth": 0.8800000000000001,
                    "color": "#b3e5fC"
                },
                "title": {
                    "display": false,
                    "text": "",
                    "padding": {
                        "top": 4,
                        "bottom": 4
                    },
                    "color": "#e1e1e1"
                },
                "alignToPixels": true,
                "id": "y",
                "position": "left"
            }
        }
    }
}

alignToPixels: true makes the border go outside. Works if its false: https://codepen.io/kurkle/pen/wvgzOYW

alignToPixels: true makes the border go outside sometimes. Works if its false:
Ok

Just a note, looks like you are using borderWidth to tune the colors, you should be using the alpha channel instead (used in that pen).
Thanks

But why do i have more GridLines ??

But why do i have more GridLines ??

If you look at the before image, first 3 bars are in "01:00" tick, next 3 bars in "04:00" tick. It is misleading.
You should be able to reduce the number of grid lines by using scriptable or indexable option for the lineWidth, but looks like I created a bug there: https://codepen.io/kurkle/pen/wvgzOYW

If you look at the before image, first 3 bars are in "01:00" tick, next 3 bars in "04:00" tick. It is misleading.

Same options only chart.js before and after fix

So your answer to the question I asked yesterday is no?

So your answer to the question I asked yesterday is no?

Sorry, yesterday I couldn't test it because the new version was released 8 hours ago...

I'm bad at communicating with people :)
I did not mean to say you should have tested it earlier/faster, I just wanted to make sure that you are indicating the fix does not work for your use case.

Could it be that there is a problem with the first and last bar element?

Or am I making a mistake?
{
    "type": "bar",
    "data": {
        "datasets": [
            {
                "label": "Energieproduktion",
                "unit": "kWh",
                "minval": 0,
                "maxval": 0,
                "sumval": 0,
                "avgval": 0,
                "pointRadius": 0,
                "current": 2.418,
                "last_changed": "2021-04-02T10:52:17.875341+00:00",
                "mode": "history",
                "backgroundColor": "#fcec34",
                "data": [
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.117,
                        "statistics": {
                            "first": 0.013,
                            "last": 0.117,
                            "max": 0.117,
                            "min": 0.013,
                            "sum": 0.316,
                            "avg": 0.063,
                            "current": 2.418
                        },
                        "localedate": "Fr, 01 Apr 21 07:07"
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.249,
                        "statistics": {
                            "first": 0.145,
                            "last": 0.249,
                            "max": 0.249,
                            "min": 0.145,
                            "sum": 1.166,
                            "avg": 0.194,
                            "current": 2.418
                        },
                        "localedate": "Fr, 01 Apr 21 08:21"
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 2.068,
                        "statistics": {
                            "first": 0.262,
                            "last": 2.068,
                            "max": 2.068,
                            "min": 0.262,
                            "sum": 8.557,
                            "avg": 1.426,
                            "current": 2.418
                        },
                        "localedate": "Fr, 01 Apr 21 09:35"
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 2.685,
                        "statistics": {
                            "first": 2.201,
                            "last": 2.67,
                            "max": 2.685,
                            "min": 2.201,
                            "sum": 15.46,
                            "avg": 2.577,
                            "current": 2.418
                        },
                        "localedate": "Fr, 01 Apr 21 10:49"
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 2.666,
                        "statistics": {
                            "first": 2.663,
                            "last": 2.613,
                            "max": 2.666,
                            "min": 2.613,
                            "sum": 15.907,
                            "avg": 2.651,
                            "current": 2.418
                        },
                        "localedate": "Fr, 01 Apr 21 11:04"
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 2.565,
                        "statistics": {
                            "first": 2.565,
                            "last": 2.326,
                            "max": 2.565,
                            "min": 2.326,
                            "sum": 14.791,
                            "avg": 2.465,
                            "current": 2.418
                        },
                        "localedate": "Fr, 01 Apr 21 12:18"
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 2.567,
                        "statistics": {
                            "first": 2.342,
                            "last": 2.567,
                            "max": 2.567,
                            "min": 2.16,
                            "sum": 13.865,
                            "avg": 2.311,
                            "current": 2.418
                        },
                        "localedate": "Fr, 01 Apr 21 13:37"
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 2.552,
                        "statistics": {
                            "first": 2.552,
                            "last": 1.607,
                            "max": 2.552,
                            "min": 1.514,
                            "sum": 11.678,
                            "avg": 1.946,
                            "current": 2.418
                        },
                        "localedate": "Fr, 01 Apr 21 14:51"
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 1.776,
                        "statistics": {
                            "first": 1.687,
                            "last": 1.468,
                            "max": 1.776,
                            "min": 1.468,
                            "sum": 9.71,
                            "avg": 1.618,
                            "current": 2.418
                        },
                        "localedate": "Fr, 01 Apr 21 15:06"
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 1.669,
                        "statistics": {
                            "first": 0.918,
                            "last": 1.339,
                            "max": 1.669,
                            "min": 0.918,
                            "sum": 7.75,
                            "avg": 1.292,
                            "current": 2.418
                        },
                        "localedate": "Fr, 01 Apr 21 16:20"
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 1.251,
                        "statistics": {
                            "first": 1.251,
                            "last": 0.312,
                            "max": 1.251,
                            "min": 0.312,
                            "sum": 5.542,
                            "avg": 0.924,
                            "current": 2.418
                        },
                        "localedate": "Fr, 01 Apr 21 17:34"
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.3,
                        "statistics": {
                            "first": 0.3,
                            "last": 0.1,
                            "max": 0.3,
                            "min": 0.1,
                            "sum": 1.293,
                            "avg": 0.215,
                            "current": 2.418
                        },
                        "localedate": "Fr, 01 Apr 21 18:49"
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.069,
                        "statistics": {
                            "first": 0.069,
                            "last": 0.001,
                            "max": 0.069,
                            "min": 0.001,
                            "sum": 0.12,
                            "avg": 0.03,
                            "current": 2.418
                        },
                        "localedate": "Fr, 01 Apr 21 19:58"
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.16,
                        "statistics": {
                            "first": 0,
                            "last": 0.16,
                            "max": 0.16,
                            "min": 0,
                            "sum": 0.481,
                            "avg": 0.08,
                            "current": 2.418
                        },
                        "localedate": "Sa, 02 Apr 21 07:57"
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.325,
                        "statistics": {
                            "first": 0.162,
                            "last": 0.325,
                            "max": 0.325,
                            "min": 0.162,
                            "sum": 1.446,
                            "avg": 0.241,
                            "current": 2.418
                        },
                        "localedate": "Sa, 02 Apr 21 08:16"
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 0.544,
                        "statistics": {
                            "first": 0.348,
                            "last": 0.544,
                            "max": 0.544,
                            "min": 0.348,
                            "sum": 2.574,
                            "avg": 0.429,
                            "current": 2.418
                        },
                        "localedate": "Sa, 02 Apr 21 09:30"
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 2.59,
                        "statistics": {
                            "first": 1.288,
                            "last": 2.59,
                            "max": 2.59,
                            "min": 1.288,
                            "sum": 13.762,
                            "avg": 2.294,
                            "current": 2.418
                        },
                        "localedate": "Sa, 02 Apr 21 10:44"
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 2.627,
                        "statistics": {
                            "first": 2.62,
                            "last": 2.622,
                            "max": 2.627,
                            "min": 2.604,
                            "sum": 13.089,
                            "avg": 2.618,
                            "current": 2.418
                        },
                        "localedate": "Sa, 02 Apr 21 11:03"
                    },
                    {
                        "x":<PHONE_NUMBER>000,
                        "y": 2.647,
                        "statistics": {
                            "first": 2.615,
                            "last": 2.418,
                            "max": 2.647,
                            "min": 2.418,
                            "sum": 15.317,
                            "avg": 2.553,
                            "current": 2.418
                        },
                        "localedate": "Sa, 02 Apr 21 12:17"
                    }
                ]
            }
        ],
        "labels": []
    },
    "options": {
        "units": "",
        "hoverOffset": 8,
        "layout": {},
        "interaction": {
            "mode": "nearest",
            "intersect": false
        },
        "chartArea": {
            "backgroundColor": "transparent"
        },
        "elements": {},
        "spanGaps": true,
        "plugins": {
            "title": {},
            "tooltip": {},
            "legend": {
                "display": false
            }
        },
        "animation": {},
        "onResize": null,
        "scales": {
            "x": {
                "axis": "x",
                "type": "time",
                "alignToPixels": true,
                "stacked": true,
                "offset": true,
                "grid": {
                    "offset": true,
                    "display": true,
                    "drawBorder": true,
                    "drawOnChartArea": true,
                    "drawTicks": true,
                    "tickLength": 8,
                    "borderDash": [
                        1,
                        1
                    ],
                    "borderDashOffset": 0,
                    "borderColor": "rgb(2, 136, 209)",
                    "borderWidth": 0.88,
                    "color": "rgba(179, 229, 252, 0.8)"
                },
                "bounds": "data",
                "adapters": {},
                "time": {
                    "parser": false,
                    "unit": false,
                    "round": false,
                    "isoWeekday": false,
                    "minUnit": "millisecond",
                    "displayFormats": {
                        "datetime": "MMM d, yyyy, h:mm:ss aaaa",
                        "millisecond": "h:mm:ss.SSS aaaa",
                        "second": "h:mm:ss aaaa",
                        "minute": "h:mm aaaa",
                        "hour": "ha",
                        "day": "MMM d",
                        "week": "PP",
                        "month": "MMM yyyy",
                        "quarter": "qqq - yyyy",
                        "year": "yyyy"
                    }
                },
                "ticks": {
                    "source": "auto",
                    "major": {
                        "enabled": false
                    },
                    "minRotation": 0,
                    "maxRotation": 50,
                    "mirror": false,
                    "textStrokeWidth": 0,
                    "textStrokeColor": "",
                    "padding": 3,
                    "display": true,
                    "autoSkip": true,
                    "autoSkipPadding": 3,
                    "labelOffset": 0,
                    "minor": {},
                    "align": "center",
                    "crossAlign": "near",
                    "color": "rgb(225, 225, 225)"
                },
                "display": true,
                "reverse": false,
                "beginAtZero": false,
                "grace": 0,
                "title": {
                    "display": false,
                    "text": "",
                    "padding": {
                        "top": 4,
                        "bottom": 4
                    },
                    "color": "rgb(225, 225, 225)"
                },
                "id": "x",
                "position": "bottom"
            },
            "y": {
                "axis": "y",
                "stacked": true,
                "type": "linear",
                "beginAtZero": true,
                "ticks": {
                    "minRotation": 0,
                    "maxRotation": 50,
                    "mirror": false,
                    "textStrokeWidth": 0,
                    "textStrokeColor": "",
                    "padding": 3,
                    "display": true,
                    "autoSkip": true,
                    "autoSkipPadding": 3,
                    "labelOffset": 0,
                    "minor": {},
                    "major": {},
                    "align": "center",
                    "crossAlign": "near",
                    "color": "rgb(225, 225, 225)"
                },
                "display": true,
                "offset": false,
                "reverse": false,
                "bounds": "ticks",
                "grace": 0,
                "grid": {
                    "display": true,
                    "drawBorder": true,
                    "drawOnChartArea": true,
                    "drawTicks": true,
                    "tickLength": 8,
                    "offset": false,
                    "borderDash": [
                        1,
                        1
                    ],
                    "borderDashOffset": 0,
                    "borderColor": "rgb(2, 136, 209)",
                    "borderWidth": 0.88,
                    "color": "rgba(179, 229, 252, 0.8)"
                },
                "title": {
                    "display": false,
                    "text": "",
                    "padding": {
                        "top": 4,
                        "bottom": 4
                    },
                    "color": "rgb(225, 225, 225)"
                },
                "alignToPixels": true,
                "id": "y",
                "position": "left"
            }
        }
    }
}

Its due to that:

"bounds": "data",

"bounds": "data",

Ok, but i do not set this attribute. Is this by default ?

https://www.chartjs.org/docs/master/axes/cartesian/time.html#time-axis-specific-options

Determines the scale bounds. more...  --> Error 404 Not found.
https://www.chartjs.org/docs/master/axes/cartesian/index.mdx#scale-bounds

Seems like it got deleted, here is the link from the current beta release where it is still in: https://www.chartjs.org/docs/next/axes/cartesian/index#scale-bounds

mdx->md rename. I'll submit a pr for those.

@kurkle

The bounds property controls the scale boundary strategy (bypassed by min/max options).
'data': makes sure data are fully visible, labels outside are removed
'ticks': makes sure ticks are fully visible, data outside are truncated

"bounds": "data" or "bounds": "ticks" --> same result, nothing changed.

@kurkle
Maybe it is based on the resize
Resize the browser, sometime it works, sometime it fails...
new testcase see: http://www.ipscon.com/test/

If the rightmost grid is always drawn, it can lead to this kind of charts:

I'm sure that does not suit all use cases.
In the above case the second last grid should probably be skipped. But we are left with one uneven tick. Some would probably want it on the left side of chart, some maybe in the middle. Depends on the use case.
BTW, does not seem to happen in the new testcase http://www.ipscon.com/test/

So this is a really tough one, but it's very unlikely we'll get a solution that works perfectly for everyone and overall the current behaviour seems to be the one with the fewest issues raised. That means that I'm marking this as wont-fix.
However, there are solutions that can live outside of the main repo. We've added a sample showing how a custom chart border could be added using a simple plugin. This would provide a way to always have borders on the right and top edges of the chart area.

@etimberg

So this is a really tough one, but it's very unlikely we'll get a solution that works perfectly for everyone and overall the current behaviour seems to be the one with the fewest issues raised. That means that I'm marking this as wont-fix.
However, there are solutions that can live outside of the main repo. We've added a sample showing how a custom chart border could be added using a simple plugin. This would provide a way to always have borders on the right and top edges of the chart area.

Unfortunately, "showing how a custom chart border" doesn't help me any further, because the new version 3.2 also has the error "Resize". Initially it usually works without errors, but when I change the size of the browser window, the error appears on the right.

The only possibility for me is to hide the vertical gridlines ...
testcase see: http://www.ipscon.com/test/

I'm experiencing the same issue since upgrading to version 3.1. Previously using latest 2.x NPM package, it worked properly. Version 3.2 always has the same problem. The rightmost grid border doesn't show up.

@zibous you test case does not produce any issues. For future, please use jsfiddle, codepen or equivalent for the test cases, where we can edit the code. Also the test cases are supposed to be minimal reproductions of the issue, so anything not related should be removed.
@jxlarrea how would you want it to function "properly" in your use case?
Some ways it could work:

skip the "21:00" and add "21:xx" on the edge
keep the "21:00" and add another line without label at the edge
add another label and let them overlap

@zibous you test case does not produce any issues. For future, please use jsfiddle, codepen or equivalent for the test cases, where we can edit the code. Also the test cases are supposed to be minimal reproductions of the issue, so anything not related should be removed.
@jxlarrea how would you want it to function "properly" in your use case?
Some ways it could work:

skip the "21:00" and add "21:xx" on the edge
keep the "21:00" and add another line without label at the edge
add another label and let them overlap

I'd expect it to work as it did in version 2.x - the rightmost border was always displayed in the previous version without any tinkering.
I actually figured out a workaround:
ticks: {
  autoSkip: true,
  maxTicksLimit: 8,
  maxRotation: 0,
  minRotation: 0,
  font: {
    family: 'Roboto'
  },
  callback: function (value, index, values) {
    if (index === 0 || index % 4 === 0 || index === values.length - 1) {
      const label = this.getLabelForValue(value);
      return label;
    } else {
      return null;
    }
  }
}

The callback function ensures that the first (index === 0) last ticks (index === values.length - 1) are always shown. Having the last one ensures that the rightmost border always shows up. After some trial and error, I found that for my particular case displaying every 4 ticks in between by using (index % 4 === 0) gives me a consistent interval between ticks displayed.
This is the result:

Regardless, in version 2 none of this was necessary as the rightmost border was always displayed, as most people would expect.

@zibous you test case does not produce any issues. For future, please use jsfiddle, codepen or equivalent for the test cases, where we can edit the code. Also the test cases are supposed to be minimal reproductions of the issue, so anything not related should be removed.

@kurkle
It happens only when scales "type": "time" all other charts works perfect.
Testcase 1:

https://codepen.io/kurkle/pen/wvgzOYW
Edit CSS
.chart {
  background-color: #333;
  width: 40%;
}
#chart{
  padding: 30px
}

Resize the browser window --> sometimes missing gridlines.
 On the sample page for bar chart, the right border/grid line is missing for me in both Edge and FireFox latest versions scaled at default 100%, on desktop (haven't tried mobile), Windows 10 scaled @ default 100% and with 1080p monitor. Should I make a new issue, or is this not worth looking into?


[Sci Comp] Develop R Function to Create User-Info JSON

Summary
Several groups have used local "syncs" of cloud storage systems to store their data (e.g., Box, Dropbox, etc.). This is not necessarily a problem but it does mean that relative file paths can't be used (or at least not for data ingestion). We've stumbled upon the idea of using a JSON to store user-specific information (including absolute file path to data and/or emails for simpler googledrive authentication) which seems like it'd work great in this context. However, so far we're prompting folx to build those JSONs manually which opens the door to user-error (and is itself a less-reproducible step). If we could develop a function to flexibly create a JSON with the desired contents that would be a really useful tool for some groups.
Starting Tasks

[x] Investigate the possibility of creating a JSON from R
[x] Develop function variant
[x] Add function to ltertools' build

[x] Look into whether the function could be made to add the JSON to the .gitignore (if the .gitignore exists...)

[x] Send updated ltertools to CRAN
[ ] Update SciComp JSON tutorial (see 'useful links' section)

Useful links

SciComp team tutorial on using JSONs for user-specific info
ltertools package GitHub repo: lter / ltertools

Dream
Ideally, we'd like to end up with something like the following:
contents <- c("path_to_data" = "users/me/documents/working_group", "email" =<EMAIL_ADDRESS>
write_json(x = contents, file = "user.json")

Substantial Progress!
Figured out how to create a JSON with custom contents from a named vector (uses RJSONIO::toJSON to do the transformation). Also developed a (simple) function variant and added the intuitive error checks (and unit tests). Pushed to ltertools repo (in dev/ directory) so will wait to see if GHAs complete without problem then work on integrating into package build.
Note too that it might be nice to expand the function to--if desired--add the file it creates to the .gitignore (if one can be found in the directory to which the JSON is exported). Would be a simple argument but less sure how simple it'd be to edit the .gitignore in place.

@njlyon0 agree that path management is a pain. Are you familiar with the here package, which seems quite similar to the approach you are taking? https://here.r-lib.org/. It even comes with a great graphic from Allison Horst:

Also, we've written up a few thoughts on this issue of referencing data files in scripts, with EDI datasets as an example for Delta, using both pins and contentid packages to make things much more portable and reproducible. Hope its helpful:
Reproducible Data Access module

Added to Package Build
make_json has been added to the package! Including unit tests, a demo in the vignette, and to NEWS.md. Need to look into the .gitignore facet though because that would be really nice to have as a built-in feature

New make_json Function Behavior
Expanded make_json with a new git_ignore argument that expects a logical. If git_ignore == TRUE--and a '.gitignore' file is found in the working directory--then the JSON file name defined in the file argument is added to the bottom of the '.gitignore'

Submitted to CRAN
Did the pre-release checks, incremented internal documentation to version 1.1.0 and sent to CRAN. If/when successfully published with make a GitHub release & make a plan for updating our website tutorial

Revised & Resubmitted
Got returned because of some weird mismatch between Authors@R field of DESCRIPTION and the computer-generated Author field. Cumbersome but cutting each author to one link (their personal website) seems to have fixed the issue (or at least it isn't flagged by devtools::check_win_devel()). Re-submitted to CRAN so hopefully it goes through this time!

Accepted by CRAN!
After the tweaks identified above, CRAN accepted 1.1.0. I made the GitHub Release and incremented the version number/package documentation to the new development version. Once the package update manifests on CRAN I should be good to move forward on updating our team tutorial to use this function

Posted on CRAN
We are live on CRAN! See here

Pull Request Opened!
I branched the team website repo (this repo), made the changes, and opened a new PR (see #13 ). I assigned Angel for review and hopefully it all looks good to her. Further details to come.

Done
Angel confirmed this looked good to her and approved the PR so I merged it.
Interesting Side Note
Turns out when I opened the PR, the way the GitHub Action was set up caused the dev branch's contents to be published on the living website. This feels not ideal (what if rendering doesn't work and thus undermines the purpose for doing this sort of dev work in a branch?) so I've tweaked the GHA .yml to--hopefully--only trigger on a commit to main. Note that this does include a merged PR but NOT the opening of a PR.


Checkout ERR_STREAM_WRITE_AFTER_END

Current behavior
App fails after the refresh checkout page https://i.imgur.com/1DyJUbO.png
Expected behavior
The page should refresh successfully
Steps to reproduce the issue
Press F5 on the checkout page at dev mode
Version of Vue Storefront

[ 1.12.2] Vue Storefront
[ ] Vue Storefront Next

Can you handle fixing this bug by yourself?

[ ] YES

[ x] NO

[ ] This is a bug report for test version on https://test.storefrontcloud.io - In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.

[ ] This is a bug report for current Release Candidate version on https://next.storefrontcloud.io - In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.

[ x] This is a bug report for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version hotfix - In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Environment details

Browser: Chrome
OS: Ubuntu 20.04
Node: 14.3.0

There is already an issue for that: https://github.com/DivanteLtd/vue-storefront/issues/4647
@gibkigonzo almost finished fix for that: https://github.com/DivanteLtd/vue-storefront/pull/4937


Aspire 9 fails to stop projects

Is there an existing issue for this?

[x] I have searched the existing issues

Describe the bug
Aspire 9 seems to have lots of problems stopping projects.
In Aspire 8, I routinely started and stopped solutions without issue.
In Aspire 9 on OSX with Podman Desktop and the Rider Aspire plugin, about half the time there are stuck ports preventing Aspire projects from running correctly. I don't know about other operating systems.
All of this is somewhat anecdotal, as I don't have a repro that happens every time, I just know I commonly have the problem. That said, I think closing open browser tabs from the previous session may reduce the incidence of this issue (that was not required with Aspire 8).
Expected Behavior
Starting, stopping, and restarting Aspire projects should "just work", including regardless of whether there are browser tabs left open from a previous run.
Steps To Reproduce
No response
Exceptions (if any)
No response
.NET Version info
IMPORTANT NOTE: I'm running via JetBrains Rider 2024.3 Build #RD-243.21565.191 on OSX, which I believe contains its own dotnet that doesn't show up using dotnet --info.

No response

Adding sample exceptions:
fail: Aspire.Hosting.Dcp.dcpctrl.ServiceReconciler[0]
      could not start the proxy {"ServiceName": {"name":"aspnetcore_project01"}, "Reconciliation": 4, "error": "could not start the proxy for the service: listen tcp [::1]:5263: bind: address already in use"}
fail: Aspire.Hosting.Dcp.dcpctrl.ServiceReconciler[0]
      could not start the proxy {"ServiceName": {"name":"aspnetcore_project03-http"}, "Reconciliation": 5, "error": "could not start the proxy for the service: listen tcp [::1]:5236: bind: address already in use"}
fail: Aspire.Hosting.Dcp.dcpctrl.ServiceReconciler[0]
      could not start the proxy {"ServiceName": {"name":"aspnetcore_project02-http"}, "Reconciliation": 12, "error": "could not start the proxy for the service: listen tcp [::1]:5019: bind: address already in use"}
fail: Aspire.Hosting.Dcp.dcpctrl.ServiceReconciler[0]
      could not start the proxy {"ServiceName": {"name":"yarp"}, "Reconciliation": 29, "error": "could not start the proxy for the service: listen tcp [::1]:6001: bind: address already in use"}
fail: Aspire.Hosting.Dcp.dcpctrl.ServiceReconciler[0]
      could not start the proxy {"ServiceName": {"name":"aspnetcore_project01"}, "Reconciliation": 30, "error": "could not start the proxy for the service: listen tcp [::1]:5263: bind: address already in use"}
fail: Aspire.Hosting.Dcp.dcpctrl.ServiceReconciler[0]
      could not start the proxy {"ServiceName": {"name":"aspnetcore_project02-http"}, "Reconciliation": 31, "error": "could not start the proxy for the service: listen tcp [::1]:5019: bind: address already in use"}
...

A coworker of mine has been getting similar issues. In that case they were running an ARM MacOS (not sure of the OS version right now) device and starting the app host using dotnet run from the command line.
Upon stopping and starting the app host, all the C# projects were failing to start since the ports were already in use.

I have the same issue. It seems like the Developer Control Pane takes up to 1 minute to shut down. I made an ugly hack to find and kill any hanging control pane as the first step when starting the AppHost.
See this commit: https://github.com/platformplatform/PlatformPlatform/commit/1772f94754c5cf455af845e8be672425ef822b49

If you are heavily impacted by this, editing your AppHost/Properties/launchSettings.json file between debugger runs to change the Dashboard port number between launches (I bump the port number up or down by 1 each time).
You still have to wait a couple seconds between ending one debugging run and starting the next, but this gives the Dashboard extra time to reset (others have reported the Dashboard is the worst/longest duration stuck port offender here).

others have reported the Dashboard is the worst/longest duration stuck port offender here

That’s what I see too. If I restart before the DCP process is ready, it sometimes takes more than a 1 minute to release the ports... but if you wait 10–15 seconds before starting, it almost always releases. In Aspire 8.2, this used to be 3-5 seconds, and in Aspire 8.0 this was not a problem at all.
The code below works for me (only tested on macOS). The only problem is that the browser starts immediately, and the dashboard is not properly shown until I manually hit refresh.
using System.Diagnostics;
using AppHost;
using Projects;

// Detect if Aspire ports from the previous run are released. See https://github.com/dotnet/aspire/issues/6704
EnsureDeveloperControlPaneIsNotRunning();

var builder = DistributedApplication.CreateBuilder(args);

// Aspire configuraiton  here...

await builder.Build().RunAsync();

void EnsureDeveloperControlPaneIsNotRunning()
{
    const string processName = "dcpctrl"; // The Aspire Developer Control Pane process name

    var process = Process.GetProcesses()
        .SingleOrDefault(p => p.ProcessName.Contains(processName, StringComparison.OrdinalIgnoreCase));

    if (process == null) return;

    Console.WriteLine($"Shutting down developer control pane from previous run. Process: {process.ProcessName} (ID: {process.Id})");

    Thread.Sleep(TimeSpan.FromSeconds(5)); // Allow Docker containers to shut down to avoid orphaned containers

    try
    {
        process.Kill();
        Console.WriteLine($"Process {process.Id} killed successfully.");
    }
    catch (Exception ex)
    {
        Console.WriteLine($"Failed to kill process {process.Id}: {ex.Message}");
    }
}

@tjementum's work around has been working great for me

Also impacted by this. Quickly stopping and restarting the application might get you in the reconciliation hell. stop, wait and start seems to solve it.
Happy to provide logs if needed.

Using the workaround of @tjementum as well by opening the task manager and filtering the processes on dcpctrl and ending the task before starting the application again.

@dbreshears putting this in 9.1

@yoDon I would appreciate a report if the latest bits in the Aspire main branch work any better for you. This PR https://github.com/dotnet/aspire/pull/6802 should help a lot.
@Kralizek yes, please, if you could share the logs, that would be very helpful
@tjementum @thomasvdb would you be wiling to share some detailed logs with us?
Killing dcpctrl is not a great long-term solution; the post-run cleanup does important things, e.g. deleting the dedicated Aspire container network, if you do not let it happen, you will run into issues like https://github.com/dotnet/aspire/issues/6639. We have seen cases when shutdown is slow because containers one uses are slow to shut down gracefully; using a persistent container in that case might be a better workaround.

Are you using Rider as well @Kralizek ? Can you reproduce this using dotnet run as well?

Also using Rider.
Never occurred in console, mostly because i use dotnet watch in console so i don't need stop/start sp quickly

We're trying to narrow down if this is a Rider issue or an aspire orchestration issue. So far it looks like the common denominator so far is rider (or some combination). Can you see if you can reproduce the issue on the command line with dotnet run? Watch has other problems.

I confirm I wasn't able to reproduce the issue with dotnet run.
$ dotnet run --project .\tools\AppHost\ --no-build
Using launch settings from .\tools\AppHost\Properties\launchSettings.json...
info: Aspire.Hosting.DistributedApplication[0]
      Aspire version: 9.0.0+01ed51919f8df692ececce51048a140615dc759d
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application starting.
info: Aspire.Hosting.DistributedApplication[0]
      Application host directory is: C:\Users\rg1844\Development\XXX\tools\AppHost
info: Aspire.Hosting.DistributedApplication[0]
      Now listening on: https://localhost:17197
info: Aspire.Hosting.DistributedApplication[0]
      Login to the dashboard at https://localhost:17197/login?t=74b0335988b84d6689b5e91c02e9f0cb
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application started. Press Ctrl+C to shut down.

$ dotnet run --project .\tools\AppHost\ --no-build
Using launch settings from .\tools\AppHost\Properties\launchSettings.json...
info: Aspire.Hosting.DistributedApplication[0]
      Aspire version: 9.0.0+01ed51919f8df692ececce51048a140615dc759d
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application starting.
info: Aspire.Hosting.DistributedApplication[0]
      Application host directory is: C:\Users\rg1844\Development\XXX\tools\AppHost
info: Aspire.Hosting.DistributedApplication[0]
      Now listening on: https://localhost:17197
info: Aspire.Hosting.DistributedApplication[0]
      Login to the dashboard at https://localhost:17197/login?t=aa42706c7ba4b03ff0518a69e1c1a4bc
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application started. Press Ctrl+C to shut down.

$ dotnet run --project .\tools\AppHost\ --no-build
Using launch settings from .\tools\AppHost\Properties\launchSettings.json...
info: Aspire.Hosting.DistributedApplication[0]
      Aspire version: 9.0.0+01ed51919f8df692ececce51048a140615dc759d
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application starting.
info: Aspire.Hosting.DistributedApplication[0]
      Application host directory is: C:\Users\rg1844\Development\XXX\tools\AppHost
info: Aspire.Hosting.DistributedApplication[0]
      Now listening on: https://localhost:17197
info: Aspire.Hosting.DistributedApplication[0]
      Login to the dashboard at https://localhost:17197/login?t=5c01df42ca2091d7edbdde3768ace4ec
info: Aspire.Hosting.DistributedApplication[0]

Here using Rider as well with this plugin: https://github.com/JetBrains/aspire-plugin

I was able to reproduce the issue with Visual Studio after a few tries. Investigating...

I frequently run into this issue in the terminal with dotnet run.

On my machine, this is the same as from the Terminal (see recording below). I also have users who have this problem when running on Windows.
If you check out https://github.com/platformplatform/PlatformPlatform and remove the workaround EnsureDeveloperControlPaneIsNotRunning(); from AppHost/Program.cs, you should be able to reproduce the problem. Again, the problem is certainly due to the ports being hardcoded in PlatformPlatform, so when restarting, Aspire tries to use the same port.

But I would not consider this fixed if the only change is randomizing the ports. In some cases I want hardcoded ports to, for example, make it easier to run tests against the locally running system.
In my opinion, the shutdown should wait until all resources are gone.

https://github.com/dotnet/aspire/pull/6931 should have fixed this, but I would appreciate a report if people still see issues with projects not stopping as they should

@karolz-ms when will this be released? we are very unpatently waiting for the fix :'D

@andrem0 I hear you. You can try the fix today with the Aspire daily builds https://github.com/dotnet/aspire/blob/main/docs/using-latest-daily.md
As for the "official" release, I think the plan of record is to have one sometime in the second half of January (plans might change).

@karolz-ms  I tried daily builds but its still not fixed for me... on m4 mac - rider..  this issue is blocking my company from switching to aspire... suggested solution above also doesnt work all time

@feritzcan2 does it reproduce when the app is run from the command line (dotnet run?). If yes, could share a repro project?

@karolz-ms  I cant share from our project unfortunatelly but we have a lot of services and we created a layer in top of aspire.
I had limited time to test on visual studio- windows, couldnt produce it. It might be only happening  on rider plugin - mac

@feritzcan2 understood, no worries. It would be really interesting to understand if the issue happens when the app host is started from command line (on the Mac), so we can differentiate between this being Aspire/DCP issue vs Aspire Rider plugin issue.
What are the errors you see in the app host output?

Those are part of errors
info: Aspire.Hosting.Dcp.dcpctrl.ExecutableReconciler[0]
process started   {"Executable": {"name":"FunctionPaymentsWorker-dnnkquvx"}, "Reconciliation": 30, "executable": "/opt/homebrew/bin/func", "PID": 47831}
info: Aspire.Hosting.Dcp.dcpctrl.ExecutableReconciler[0]
starting process...       {"Executable": {"name":"FunctionSessionsFunction-fwtkrgqd"}, "Reconciliation": 31, "executable": "/opt/homebrew/bin/func"}
info: Aspire.Hosting.Dcp.dcpctrl.ExecutableReconciler[0]
process started   {"Executable": {"name":"FunctionSe-fwtkrgqd"}, "Reconciliation": 31, "executable": "/opt/homebrew/bin/func", "PID": 47834}
info: Aspire.Hosting.Dcp.dcpctrl.ServiceReconciler[0]
could not use the same port for all addresses associated with requested service address, service will be reachable only using specific IP address      {"ServiceName": {"name":"bff-https"}, "Reconciliation": 29, "AttemptedCommonPort": 7201, "RequestedServiceAddress": "localhost"}
fail: Aspire.Hosting.Dcp.dcpctrl.ServiceReconciler[0]

@feritzcan2 thank you
When you start the application, please take a note the path to the dcp and dcpctrl processes that the Aspire application host is launching. Then from the command line do <path-to-dcp-executable>/dcp version. It should be version 0.9.2. If it is anything else, you are not running the latest.
If that checks out, would you be willing to send me detailed execution logs? You can reach me at (the part of my GH alias before<EMAIL_ADDRESS>and I will send you instructions.

@karolz-ms yes it seems like its not using latest version. But we have nuget config and I set dotnet9 source there. What else should I do?

Thanks @feritzcan2
To verify, I followed the instructions in https://github.com/dotnet/aspire/blob/main/docs/using-latest-daily.md. I do recommend to create a local nuget.config file to avoid changing your global Nuget configuration.
After the application is built and started search for dcp process and note the path
> ps aux | grep dcp

...
karolz           37808   0.0  0.2 35441568  52788 s005  S     8:59AM   0:01.62
/Users/karolz/.nuget/packages/aspire.hosting.orchestration.osx-x64/9.1.0-preview.1.24619.1/tools/dcp
start-apiserver --monitor 37740 (other parameters)

Verify the version
> /Users/karolz/.nuget/packages/aspire.hosting.orchestration.osx-x64/9.1.0-preview.1.24619.1/tools/dcp version
{"version":"0.9.2","commitHash":"e1586b9dd7b6b4bb15cf0b81000ba8ec55854887","buildTimestamp":"2024-12-11T17:11:30Z"}

0.9.2 is what you want.
Here is my local nuget.config, note the dotnet9 source that enables getting latest daily Aspire builds
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <!--To inherit the global NuGet package sources remove the <clear/> line below -->
    <clear />
    <add key="nuget" value="https://api.nuget.org/v3/index.json" />
    <add key="dotnet9" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet9/nuget/v3/index.json" />
  </packageSources>
</configuration>

... and the AppHost project, note SDK and Aspire.Hosting.AppHost references
<Project Sdk="Microsoft.NET.Sdk">

  <Sdk Name="Aspire.AppHost.Sdk" Version="9.1.0-preview.1.24619.1" />

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <IsAspireHost>true</IsAspireHost>
    <UserSecretsId>93445db8-0185-405d-8d0e-84e3c7e02bd1</UserSecretsId>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="..\starterapp.ApiService\starterapp.ApiService.csproj" />
    <ProjectReference Include="..\starterapp.Web\starterapp.Web.csproj" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="Aspire.Hosting.AppHost" Version="9.1.0-preview.1.24619.1" />
  </ItemGroup>

</Project>

Hope this helps! LMK if after switching ot DCP 0.9.2 your app is shut down properly or not--TIA

@karolz-ms  unfortunatelly still not working :(
info: Aspire.Hosting.Dcp.dcpctrl.ServiceReconciler[0]
could not use the same port for all addresses associated with requested service address, service will be reachable only using specific IP address       {"ServiceName": {"name":"pay-https"}, "Reconciliation": 65, "AttemptedCommonPort": 52258, "RequestedServiceAddress": "localhost"}

@feritzcan2 is this the only unusual message that you see? Note that this is an "info" message, not an error--the app should still work, although connecting to pay-https service may be slow. Is the app working?
Regarding port that the message mentions (52258):

Is it part of the application configuration? In particular, does it show up in any launchsettings.json file?
When the application is stopped (and all the application processes are cleaned up, manually if necessary): is there another process on the machine that is listening on that port? Do lsof -i @localhost to check please

@karolz-ms  Hey karol, unfortunatelly there is also error that i didnt share...  It happens almost everytime I stop and start immediately, and cannot send requests to the ports that I m using.
I'm sharing only part of log but that fail logs exist for all services
fail: Aspire.Hosting.Dcp.dcpctrl.ServiceReconciler[0]
could not start the proxy {"ServiceName": {"name":"payment-https"}, "Reconciliation": 160, "error": "could not start the proxy for the service: listen tcp [::1]:52258: bind: address already in use"}
info: Aspire.Hosting.Dcp.dcpctrl.ServiceReconciler[0]
could not use the same port for all addresses associated with requested service address, service will be reachable only using specific IP address       {"ServiceName": {"name":"payment-http"}, "Reconciliation": 161, "AttemptedCommonPort": 52257, "RequestedServiceAddress": "localhost"}

Running that command for DCP process running  also validates I'm running 9.1.0
ps xuwww -p 35241
USER        PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
fx 35241   0.2  0.1 411919040  74528 s000  S    12:07PM   0:02.43 /Users/fx/.nuget/packages/aspire.hosting.orchestration.osx-arm64/9.1.0-preview.1.24619.1/tools/dcp start-apiserver --monitor 35204 --kubeconfig /var/folders/gz/10gsc5ts1xb1kq6ptm52k3k80000gn/T/aspire.PuOBWE/kubeconfig --container-runtime

@feritzcan2 thank you. Would you be willing to send me detailed logs from the failing run? Email me please for instructions if yes--thanks in advance!

@karolz-ms yeah I also reallywant to see this is fixed , sending you an email

Status update: I got the logs from @feritzcan2 (many thanks!) that revealed another case where the Executable shutdown is not done as quickly as it can and should, which causes subsequent run to time out trying to acquire the TCP port. Working on a fix...


Don't send app lifecycle events unless there's a listener

Repro steps
On macOS:

Using a locally built engine, run the spinning square example or any app that doesn't use the widgets layer
Hide/show the window a few times

You'll see the following errors in the console:
> flutter run --local-engine host_debug_unopt -d macos  ./raw/spinning_square.dart
flutter: A message on the flutter/lifecycle channel was discarded before it could be handled.
This happens when a plugin sends messages to the framework side before the framework has had an opportunity to register a listener. See the ChannelBuffers API documentation for details on how to configure the channel to expect more messages, or to expect messages to get discarded:
  https://api.flutter.dev/flutter/dart-ui/ChannelBuffers-class.html
The capacity of the flutter/lifecycle channel is 1 message.

Solution
We shouldn't send flutter/lifecycle messages unless the Dart app has a listener for that channel.
/cc @gspencergoog

@bleroux provided the excellent solution that we could set the lifecycle channel's size to 0 so that messages are dropped if the framework isn't subscribed. If we go with this approach, we'd likely want to add a "synchronize state" message to the lifecycle channel so that the framework can get its initial state at start up.

Great!
For clarification, if the only goal is to remove the error messages, the solution is not to set the buffer size to 0 but to allow the channel to overflow (see https://github.com/flutter/engine/blob/93e8901490e78c7ba7e319cce4470d9c6478c6dc/lib/ui/channel_buffers.dart#L304C1-L309C35).
Setting the buffer size to 0 makes sense if the buffered message could be obsolete when delivered (this is the case in order to fix https://github.com/flutter/flutter/issues/125975).
FYI, I’m working on several PRs to add helper functions for the ‘resize’ and ‘overflow’ commands (see https://github.com/flutter/flutter/issues/132386).
I filed https://github.com/flutter/engine/pull/44636 for Linux and https://github.com/flutter/engine/pull/44434 for Android.
I plan to file the macOS implementation at the end of next week. And the Windows one the week after.

I've tried manipulating the buffer size before, and when I was initially implementing the lifecycle events I had a little trouble manipulating the buffer size at startup time, simply because the Dart isolate wasn't up and running yet when I needed to set the buffer size.  Since the buffer sizing code is in Dart, it doesn't actually change the buffer size in that case.
This might not be an issue here, but I thought I'd mention it.

This is still planned work. It seems like setting the buffer size to zero isn't going to work here, for the reasons I outlined above, so we'll need to add a mechanism for telling the engine when listeners have subscribed and unsubscribed. The alternative would be to move the buffering code into each platform implementation so it can take effect even if the Dart isolate isn't running yet, which seems like a lot of duplicated code.

FYI, this was fixed on Windows by introducing a "channel updates" embedder API (here, here). The Windows embedder uses this callback to drop lifecycle events (here) until it is notified that the Dart app is listening to the flutter/lifecycle channel (here, here)


SwiftSyntax doesn't build on macOS version < 13

Trying to update SwiftSyntax from 509.0.0-swift-DEVELOPMENT-SNAPSHOT-2023-07-09-a to 509.0.0-swift-DEVELOPMENT-SNAPSHOT-2023-08-07-a I faced compile errors in a macOS 12 VM. A few examples:
/Users/runner/work/1/s/.build/checkouts/swift-syntax/Sources/SwiftSyntax/SyntaxCollection.swift:363:53: error: cannot specialize protocol type 'Sequence'
  public static func += (lhs: inout Self, rhs: some Sequence<Element>) {
                                                    ^
/Users/runner/work/1/s/.build/checkouts/swift-syntax/Sources/SwiftSyntax/Raw/RawSyntaxLayoutView.swift:61:25: error: cannot specialize protocol type 'Collection'
    with elements: some Collection<RawSyntax?>,
                        ^
/Users/runner/work/1/s/.build/checkouts/swift-syntax/Sources/SwiftSyntax/Raw/RawSyntax.swift:823:27: error: cannot specialize protocol type 'Collection'
    from collection: some Collection<RawSyntax?>,
                          ^
/Users/runner/work/1/s/.build/checkouts/swift-syntax/Sources/SwiftSyntax/SyntaxCollection.swift:363:53: error: cannot specialize protocol type 'Sequence'
  public static func += (lhs: inout Self, rhs: some Sequence<Element>) {
                                                    ^

It seems that opaque types like some Collection<Element> and the like require a certain SDK version. In case of macOS, such a supporting SDK is only available from macOS 13. Package.swift specifies macOS 10.15 as a minimum. That seems to be too low if the erring opaque types are now in use in SwiftSyntax' code base.

Tracked in Apple’s issue tracker as rdar://114658666

@SimplyDanny Which version of Xcode and (if applicable) which Swift Open Source Toolchain do you have installed on the macOS 12 VM? The OS itself shouldn’t make a difference, just the SDK that’s installed in Xcode. My assumption is that you have Xcode 14.0 installed because it comes with the macOS 12 SDK but the Swift 5.7 compiler.
I agree that we might have a mismatch here that needs to be fixed. I just want to understand the issue fully before jumping to any conclusions.

The following is assuming that you are using Xcode 14.0 or 14.0.1.
This is an issue in Xcode. Xcode 14.0 contains the Swift 5.7 compiler but the macOS 12.3 SDK, which contains the Swift 5.6 standard library. Since that standard library doesn’t declare Sequence and Collection with primary associated types, they don’t compile. So, the deployment target declaration in swift-syntax is correct and the fix is that you need to update your Xcode to 14.1 or later.

Thank you for your fast reply and helpful hints!
Yes, indeed with Xcode 14.1 on macOS 12 it compiles.
Just to make sure my understanding is correct, as I always get a little confused by these different players involved: In oder to compile SwiftSyntax, we need at least a Swift 5.7 compiler together with a version of the Swift Standard Library that declares Sequence and Collection with primary associated types (among other features). This library is provided in the macOS SDK starting from version 13. Both come with Xcode 14.1 independent of the OS it is running on. As primary associated types don't require runtime support, the actual deployment target can be lower than the SDK version. Xcode would complain if SwiftSyntax was using an API that's unavailable on any of the supported deployment targets.
The minimum deployment target is specified in Package.swift. But how does one know which Swift and SDK version is required to build a package successfully?

Just to make sure my understanding is correct…

Everything correct

The minimum deployment target is specified in Package.swift. But how does one know which Swift and SDK version is required to build a package successfully?

That’s what we use the swift-tools-version in the package manifest for. If your Swift is older than that version, swift-syntax won’t compile. The only catch here is that this checks the compiler version, not the stdlib version and Xcode 14 is a weirdo in that regard because it contains a different stdlib version in the macOS SDK than the compiler it ships with.

The minimum deployment target is specified in Package.swift. But how does one know which Swift and SDK version is required to build a package successfully?

That’s what we use the swift-tools-version in the package manifest for. If your Swift is older than that version, swift-syntax won’t compile. The only catch here is that this checks the compiler version, not the stdlib version and Xcode 14 is a weirdo in that regard because it contains a different stdlib version in the macOS SDK than the compiler it ships with.

I see. Normally, the compiler comes with a matching standard library. With the mismatch in Xcode 14, I just trapped into an exceptional case.
Sorry, if this was a bit off-topic. Closing the issue. Thanks @ahoppen!

No problem at all. I was happy to explain it. And thanks for raising the issue. It might have been something more serious.


Container startup with option no-new-privileges get stuck in containerd version 1.4.4

Description
Docker run command with option --security-opt=no-new-privileges gets stuck
This issue is originated from k8s where kubelet reports PLEG unhealthy message when CoreDNS starts up.
While checking the spec of CoreDNS, we found that there is a security context set for the coredns container.
        securityContext:
          allowPrivilegeEscalation: false

This option will add flag no_new_priv to the container.
When we remove the security context, the container starts up fine.
Steps to reproduce the issue:

Deploy a node with Ubuntu 18 with latest docker and containerd version 1.4.4.-1
Run a loop to create containers

while true; do docker run -itd --security-opt=no-new-privileges leodotcloud/swiss-army-knife ; done

Wait for docker run command to get stuck (it get stuck after creating ~170 containers)

Describe the results you received:
The "runc init" command is the one that gets stuck
Doing an strace on "runc init" causes the docker run command to exit . The strace output will end like below
strace: Process 3423 attached
futex(0x560028b1dbd0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x560028b1dad0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0xc000040848, FUTEX_WAKE_PRIVATE, 1) = 1
epoll_ctl(8, EPOLL_CTL_DEL, 6, 0xc0001d6ca4) = 0
...
futex(0x560028b1dbd0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x560028b1dad0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0xc000040848, FUTEX_WAKE_PRIVATE, 1) = 1
...
read(4, "", 8)                          = 0
epoll_ctl(8, EPOLL_CTL_DEL, 4, 0xc0001d6c7c) = 0
close(4)                                = 0
futex(0x560028b1e508, FUTEX_WAIT_PRIVATE, 0, NULL) = -1 EAGAIN (Resource temporarily unavailable)
seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_LOG, NULL) = -1 EFAULT (Bad address)
seccomp(SECCOMP_GET_ACTION_AVAIL, 0, [SECCOMP_RET_LOG]) = 0
prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, {len=526, filter=0xc0002a2000}) = -1 EINVAL (Invalid argument)
write(2, "standard_init_linux.go:207: init"..., 132) = 132
futex(0x560028b1e508, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
exit_group(1)                           = ?
+++ exited with 1 +++

Describe the results you expected:
No stuck containers during the creation
What version of containerd are you using:
$ containerd --version
containerd containerd.io 1.4.4 05f951a3781f4f2c1911b05e61c160e9c30eaa8e

Any other relevant information (runC version, CRI configuration, OS/Kernel version, etc.):
pprof_goroutines attached here
runc --version
runc version 1.0.0-rc93
commit: 12644e614e25b05da6fd08a38ffa0cfe1903fdec
spec: 1.0.2-dev
go: go1.13.15
libseccomp: 2.4.3

crictl info
$ crictl info
WARN[0000] runtime connect using default endpoints: [unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock]. As the default settings are now deprecated, you should set the endpoint instead.
ERRO[0002] connect endpoint 'unix:///var/run/dockershim.sock', make sure you are running as root and the endpoint has been started: context deadline exceeded
FATA[0002] getting status of runtime: rpc error: code = Unimplemented desc = unknown service runtime.v1alpha2.RuntimeService
After commenting #disabled_plugins = ["cri"] in config.toml
{
"status": {
"conditions": [
{
"type": "RuntimeReady",
"status": true,
"reason": "",
"message": ""
},
{
"type": "NetworkReady",
"status": false,
"reason": "NetworkPluginNotReady",
"message": "Network plugin returns error: cni plugin not initialized"
}
]
},
"cniconfig": {
"PluginDirs": [
"/opt/cni/bin"
],
"PluginConfDir": "/etc/cni/net.d",
"PluginMaxConfNum": 1,
"Prefix": "eth",
"Networks": [
{
"Config": {
"Name": "cni-loopback",
"CNIVersion": "0.3.1",
"Plugins": [
{
"Network": {
"type": "loopback",
"ipam": {},
"dns": {}
},
"Source": "{"type":"loopback"}"
}
],
"Source": "{\n"cniVersion": "0.3.1",\n"name": "cni-loopback",\n"plugins": [{\n  "type": "loopback"\n}]\n}"
},
"IFName": "lo"
}
]
},
"config": {
"containerd": {
"snapshotter": "overlayfs",
"defaultRuntimeName": "runc",
"defaultRuntime": {
"runtimeType": "",
"runtimeEngine": "",
"PodAnnotations": null,
"ContainerAnnotations": null,
"runtimeRoot": "",
"options": null,
"privileged_without_host_devices": false,
"baseRuntimeSpec": ""
},
"untrustedWorkloadRuntime": {
"runtimeType": "",
"runtimeEngine": "",
"PodAnnotations": null,
"ContainerAnnotations": null,
"runtimeRoot": "",
"options": null,
"privileged_without_host_devices": false,
"baseRuntimeSpec": ""
},
"runtimes": {
"runc": {
"runtimeType": "io.containerd.runc.v2",
"runtimeEngine": "",
"PodAnnotations": null,
"ContainerAnnotations": null,
"runtimeRoot": "",
"options": {},
"privileged_without_host_devices": false,
"baseRuntimeSpec": ""
}
},
"noPivot": false,
"disableSnapshotAnnotations": true,
"discardUnpackedLayers": false
},
"cni": {
"binDir": "/opt/cni/bin",
"confDir": "/etc/cni/net.d",
"maxConfNum": 1,
"confTemplate": ""
},
"registry": {
"mirrors": {
"docker.io": {
"endpoint": [
"https://registry-1.docker.io"
]
}
},
"configs": null,
"auths": null,
"headers": null
},
"imageDecryption": {
"keyModel": ""
},
"disableTCPService": true,
"streamServerAddress": "<IP_ADDRESS>",
"streamServerPort": "0",
"streamIdleTimeout": "4h0m0s",
"enableSelinux": false,
"selinuxCategoryRange": 1024,
"sandboxImage": "k8s.gcr.io/pause:3.2",
"statsCollectPeriod": 10,
"systemdCgroup": false,
"enableTLSStreaming": false,
"x509KeyPairStreaming": {
"tlsCertFile": "",
"tlsKeyFile": ""
},
"maxContainerLogSize": 16384,
"disableCgroup": false,
"disableApparmor": false,
"restrictOOMScoreAdj": false,
"maxConcurrentDownloads": 3,
"disableProcMount": false,
"unsetSeccompProfile": "",
"tolerateMissingHugetlbController": true,
"disableHugetlbController": true,
"ignoreImageDefinedVolumes": false,
"containerdRootDir": "/var/lib/containerd",
"containerdEndpoint": "/run/containerd/containerd.sock",
"rootDir": "/var/lib/containerd/io.containerd.grpc.v1.cri",
"stateDir": "/run/containerd/io.containerd.grpc.v1.cri"
},
"golang": "go1.13.15",
"lastCNILoadStatus": "cni config load failed: no network config found in /etc/cni/net.d: cni plugin not initialized: failed to load cni config"
}

uname -a
Linux k8s-u18-worker01 4.15.0-139-generic #143-Ubuntu SMP Tue Mar 16 01:30:17 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

After downgrading to 1.4.3-1 , the issue won't appear

https://github.com/opencontainers/runc/issues/2865 is possibly related to this

Thanks @Oats87
I couldn’t repro the issue after replacing  runc 1.0.0-rc93 with 1.0.0-rc92
https://github.com/opencontainers/runc/releases/tag/v1.0.0-rc92

Is this issue closable then?

Bug is on runc, hence closing this issue.

I can repro easily in an AKS cluster with rc93. rc92 works just fine. However I've only ever seen the issue with io.containerd.runtime.linux.v1, not io.containerd.runc.v2.
As soon as I strace the runc init it exits.
We do not use no-new-privileges.

@ansilh What version of Docker is that?

@cpuguy83
Docker Version: 19.03.15
docker info
Client:
 Debug Mode: false

Server:
 Containers: 175
  Running: 160
  Paused: 0
  Stopped: 15
 Images: 13
 Server Version: 19.03.15
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 05f951a3781f4f2c1911b05e61c160e9c30eaa8e
 runc version: 12644e614e25b05da6fd08a38ffa0cfe1903fdec
 init version: fec3683
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 4.15.0-130-generic
 Operating System: Ubuntu 18.04.5 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 3.853GiB
 Name: k8s-worker-istio-03
 ID: HWZ6:SXPX:CPQC:P3O2:XJ6V:FMUL:X2O3:NFR2:53MZ:CO4D:CXAK:BTHF
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  <IP_ADDRESS>/8
 Live Restore Enabled: false

Ok yeah that's the v1 shim as well.


You can use 'type' to do this

obj = type("MyObject", (object, ), {"b1":"v1", "b2":"v2"})
obj.b1 #outputs 'v1'

That's just class generation.  I'm guessing you didn't read the whole README ;)
DStruct isn't merely about not using dictionaries (there's nothing wrong with dictionaries); it's about using instances of classes that can be declaratively restricted in schema.


Add support for vxworks 5.0 in builtin script VxWorksSymTab_Finder.java

Describe the solution you'd like
It should be a simple matter of adding a case in private VxSymbol getVxSymbolClass(int type) . Vxworks 5.3 has a slightly different struct SYMBOL from the other versions already supported.
Describe alternatives you've considered
I temporarily cannot test /implement this until I can run scripts (need to resolve unrelated issues)
Additional context
From symbol.h revision "02c,22sep92" , in a release tagged 5.3 (15mar96) :
typedef struct			/* SYMBOL - entry in symbol table */
    {
    SL_NODE	nameHNode;	/* hash node (must come first) */
    char	*name;		/* pointer to symbol name */
    char	*value;		/* symbol value */
    UINT16	group;		/* symbol group */
    SYM_TYPE	type;		/* symbol type */
    } SYMBOL;

SYM_TYPE defaults to a signed char, int8

Edit - vx 5.3 should alreadby be handled properly . My ROM was actually based on vx 5.0 !
Submitting a PR shortly.


headerCheckboxable option isn't working as expected.

I'm submitting a ...  (check one with "x")
[ x ] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, post on Stackoverflow or Gitter

Current behavior
The headerCheckboxable option isn't working as expected.
Expected behavior
The header checkbox option must "watch" the others checkboxes, as soon as all checkboxes are ticked it must be checked also, otherwise, if there's one checkbox deselected it should be automatically deselected also.
Reproduction of the problem
Go to #checkbox demo and follow the steps:

Select the header checkbox;
Deselect a register (now the bug starts, you'll note that the header doesn't deselects automatically, but it would since there's one register deselected);
Deselect the header checkbox (It will check all checkboxes and only he will be deselected);
Select the header checkbox (It will uncheck all checkboxes and only he will be selected);

Table version: 9.0.0

Angular version: 4.0.03

I observed the same behavior.
Same issue was reported by me here: https://github.com/swimlane/ngx-datatable/issues/659 . It's marked as solved, but I just tried with version 9.0.0 and it's still actual.

Same issue with my project.

This is a duplicate of #659. I've created a pull request (#719) to fix this issue.

I added some comments to the review, if we can get together on those items happy to merge!

Working for me in the latest (9.1.0).

I am working with Angular 2, can you please help me in implementing this with<EMAIL_ADDRESS>and I am able to succeed in presenting Show/Hide columns, sorting, pagination, Individual selection with the check box. But I am failing to get select all.

@MorlaRamakrishna It's fixed since version 9.1.0 but that requires you to switch to Angular 4. You can check what has changed in #719.

Is there any solution to fix this issue without upgrading to Angular 4.


Align comments-time-machine-links banner to the site header

Fixes #4227
Test URLs
https://github.com/sindresorhus/refined-github/blob/main/media/promo.png?rgh-link-date=2017-04-12T07%3A11%3A49Z
Screenshot

Hard to see the alignment in the screenshot if the window is 20px larger than the body width 😃

Isn't that what you wanted?

Either we align it with the black header or we align it with the repo.

Look on the right side. It's not aligned

Ah sorry, I recreated the change in my developer tools but I didn't notice you also flipped the position of the button in the DOM. It works correctly and I also dropped the wrapper now. I had resolved the review because my next comment made me think that d-flex was going to be needed anyway.


fix aarch64 build

This patch fixes an error when trying to build under the aarch64 because the compiler there does not know the option -m64 and fails when gets it.
Below is attached a part of relevant build log:
if [ aarch64 = 'aarch64' ]; then echo -e "1\n2\n" | ./configure; fi
---------------------------------------------------------------------
SoftEther VPN for Unix

Copyright (c) SoftEther VPN Project at University of Tsukuba, Japan.
Copyright (c) Daiyuu Nobori. All Rights Reserved.

This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
version 2 as published by the Free Software Foundation.

Read and understand README.TXT, LICENSE.TXT and WARNING.TXT before use.
---------------------------------------------------------------------

Welcome to the corner-cutting configure script !

The Makefile is generated. Run 'make' to build SoftEther VPN.
if [ aarch64 = 'armv7l' ]; then echo -e "1\n1\n" | ./configure; fi
dh override_dh_auto_configure
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
   dh_auto_build -a
	make -j1
make[1]: Entering directory '/<<PKGBUILDDIR>>'
cc -DNDEBUG -DVPN_SPEED -DUNIX -DUNIX_LINUX -DCPU_64 -D_REENTRANT -DREENTRANT -D_THREAD_SAFE -D_THREADSAFE -DTHREAD_SAFE -DTHREADSAFE -D_FILE_OFFSET_BITS=64 -I./src/ -I./src/Cedar/ -I./src/Mayaqua/ -O2 -fsigned-char -m64 -c src/Mayaqua/Cfg.c -o tmp/objs/Mayaqua/Cfg.o
cc: error: unrecognized command line option ‘-m64’
Makefile:64: recipe for target 'tmp/objs/Mayaqua/Cfg.o' failed
make[1]: *** [tmp/objs/Mayaqua/Cfg.o] Error 1
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
dh_auto_build: make -j1 returned exit code 2
debian/rules:8: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

Here is the link to full build log: https://launchpadlibrarian.net/295367949/buildlog_ubuntu-xenial-arm64.softether-vpn_4.04.9412-0~201611270843~ubuntu16.04.1_BUILDING.txt.gz

@dnobori, that really fixes build for aarch64, I've tested it, could you please merge? I've built packages with it in https://github.com/paskal/SoftEtherVPN-debian.

Thank you so much for your contribution to enrich the SoftEther VPN source code.
Your patch has been merged on the main source-tree of SoftEther VPN.
As a token of our gratitude, your GitHub username will be added on the AUTHORS.TXT file. (It will be done within a few days.)
https://github.com/SoftEtherVPN/SoftEtherVPN/blob/master/AUTHORS.TXT
Thanks again for your contribution.


When deleting a deployment fails a success message is displayed

Describe the Bug
Trying to delete a deployment always return a success message, even in case of failure
Steps to Reproduce the Bug or Issue

Go to the Deployments view

Delete a kamelet (on operate first there's no permission to delete, hence always returning an error)

Notice how despite the call failing, a success message is displayed to the user

Screenshots or Videos
No response
Platform

OS: [Linux]
Browser: [Firefox]
Version: [0.7.2-dev]


Request for headers in nav pane

File: engine/api/v1.24.md
It would be nice if in the "On this page" navigation pane on the side, if the sections could also show the headers of what's in them (like an anchor to "Get container logs" under the container section).  Navigating the page would be significantly easier

Let me do a POC, but it might make it really cluttered. Stay tuned.

Actually after v1.24, we are using swagger for this, so whatever change i do won't be very effective. See https://docs.docker.com/engine/api/v1.25/#tag/Container which already meets your needs.