'rcn=4' vs 'rcn=4&fu=1' differences

i believe there is an issue rendering attributes+child_resources responses, nesting of the resources in the response is different between retrieve and discovery, and i don't believe this is justified in the spec.
for example,
http://<IP_ADDRESS>:8081/id-in?rc=4 returns
{
    "m2m:cb": {
        "ri": "id-in",
        "ty": 5,
        "rn": "cse-in",
        "csi": "/id-in",
        "acpi": [
            "acpAdmin"
        ],
        "ct": "20200609T200331,388077",
        "lt": "20200609T202105,236548",
        "et": "20210609T200331,388176",
        "pi": "",
        "rr": false,
        "srt": [
            1,
            2,
            3,
            4,
            5,
            9,
            13,
            14,
            16,
            23,
            28,
            52
        ],
        "csz": [
            "application/json"
        ],
        "srv": [
            "3"
        ],
        "poa": [
            "http://<IP_ADDRESS>:8080"
        ],
        "cst": 1,
        "nl": "nod861042590844046387",
        "m2m:acp": [
            {
                "ri": "acp1028273287565921797",
                "rn": "acp_statistics",
                "ct": "20200609T200338,574776",
                "lt": "20200609T200338,574776",
                "et": "20210609T200338,574845",
                "pi": "id-in",
                "ty": 1,
                "pv": {
                    "acr": [
                        {
                            "acop": 63,
                            "acor": [
                                "CAdmin",
                                "CX677vJit2W"
                            ]
                        }
                    ]
                },
                "pvs": {
                    "acr": [
                        {
                            "acop": 51,
                            "acor": [
                                "CAdmin"
                            ]
                        }
                    ]
                }
            },
            {
                "ty": 1,
                "ri": "acpAdmin",
                "rn": "adminACP",
                "pi": "id-in",
                "pv": {
                    "acr": [
                        {
                            "acor": [
                                "CAdmin"
                            ],
                            "acop": 63
                        }
                    ]
                },
                "pvs": {
                    "acr": [
                        {
                            "acor": [
                                "CAdmin"
                            ],
                            "acop": 55
                        }
                    ]
                },
                "ct": "20200609T200331,455044",
                "lt": "20200609T200331,455044",
                "et": "20210609T200331,455162"
            },
            {
                "ty": 1,
                "ri": "acpDefault",
                "rn": "defaultACP",
                "pi": "id-in",
                "pv": {
                    "acr": [
                        {
                            "acor": [
                                "CDefault",
                                "CAdmin"
                            ],
                            "acop": 63
                        }
                    ]
                },
                "pvs": {
                    "acr": [
                        {
                            "acor": [
                                "CAdmin"
                            ],
                            "acop": 55
                        }
                    ]
                },
                "ct": "20200609T200331,513529",
                "lt": "20200609T200331,513529",
                "et": "20210609T200331,513600"
            }
        ],
        "m2m:ae": [
            {
                "rn": "statistics",
                "api": "ae-statistics",
                "nl": "nod861042590844046387",
                "poa": [
                    "http://<IP_ADDRESS>:8080"
                ],
                "rr": true,
                "srv": [
                    "3",
                    "4"
                ],
                "ri": "CX677vJit2W",
                "ct": "20200609T200338,558810",
                "lt": "20200609T200338,558810",
                "et": "20210609T200338,558877",
                "pi": "id-in",
                "ty": 2,
                "aei": "CX677vJit2W",
                "acpi": [
                    "acp1028273287565921797"
                ],
                "acme:csest": [
                    {
                        "rn": "statistics",
                        "cnd": "acme.statistics",
                        "acpi": [
                            "acp1028273287565921797"
                        ],
                        "mni": 10,
                        "rmRes": 4984,
                        "crRes": 5003,
                        "htRet": 2251,
                        "htCre": 6,
                        "htUpd": 5114,
                        "htDel": 0,
                        "lgErr": 4,
                        "lgWrn": 9540,
                        "cseSU": "20200708T005406,868457",
                        "cseUT": "0:31:12",
                        "ctRes": 19,
                        "ri": "csest2319516495356652035",
                        "ct": "20200609T200338,971435",
                        "lt": "20200707T182519,810517",
                        "et": "20210609T200338,971524",
                        "pi": "CX677vJit2W",
                        "st": 5006,
                        "ty": 28,
                        "cs": 375,
                        "cr": "CX677vJit2W",
                        "cni": 10,
                        "acme:csest": [
                            {
                                "rn": "statistics_4997",
                                "rmRes": 4975,
                                "crRes": 4994,
                                "htRet": 2212,
                                "htCre": 6,
                                "htUpd": 5099,
                                "htDel": 0,
                                "lgErr": 4,
                                "lgWrn": 9540,
                                "cseSU": "20200708T005406,868457",
                                "cseUT": "0:29:41",
                                "ctRes": 19,
                                "acpi": [
                                    "acp1028273287565921797"
                                ],
                                "ri": "csest1794142844999499776",
                                "ct": "20200707T182348,711692",
                                "lt": "20200707T182348,711692",
                                "et": "20210707T182348,711708",
                                "pi": "csest2319516495356652035",
                                "st": 0,
                                "ty": 52,
                                "cs": 375
                            },
                            {
                                "rn": "statistics_4998",
                                "rmRes": 4976,
                                "crRes": 4995,
                                "htRet": 2213,
                                "htCre": 6,
                                "htUpd": 5100,
                                "htDel": 0,
                                "lgErr": 4,
                                "lgWrn": 9540,
                                "cseSU": "20200708T005406,868457",
                                "cseUT": "0:29:51",
                                "ctRes": 19,
                                "acpi": [
                                    "acp1028273287565921797"
                                ],
                                "ri": "csest3357060219620329572",
                                "ct": "20200707T182358,823487",
                                "lt": "20200707T182358,823487",
                                "et": "20210707T182358,823501",
                                "pi": "csest2319516495356652035",
                                "st": 0,
                                "ty": 52,
                                "cs": 375
                            },
                            {
                                "rn": "statistics_4999",
                                "rmRes": 4977,
                                "crRes": 4996,
                                "htRet": 2213,
                                "htCre": 6,
                                "htUpd": 5101,
                                "htDel": 0,
                                "lgErr": 4,
                                "lgWrn": 9540,
                                "cseSU": "20200708T005406,868457",
                                "cseUT": "0:30:02",
                                "ctRes": 19,
                                "acpi": [
                                    "acp1028273287565921797"
                                ],
                                "ri": "csest4226788739776195818",
                                "ct": "20200707T182408,912666",
                                "lt": "20200707T182408,912666",
                                "et": "20210707T182408,912689",
                                "pi": "csest2319516495356652035",
                                "st": 0,
                                "ty": 52,
                                "cs": 375
                            },
                            {
                                "rn": "statistics_5000",
                                "rmRes": 4978,
                                "crRes": 4997,
                                "htRet": 2213,
                                "htCre": 6,
                                "htUpd": 5105,
                                "htDel": 0,
                                "lgErr": 4,
                                "lgWrn": 9540,
                                "cseSU": "20200708T005406,868457",
                                "cseUT": "0:30:12",
                                "ctRes": 19,
                                "acpi": [
                                    "acp1028273287565921797"
                                ],
                                "ri": "csest2267622056735906608",
                                "ct": "20200707T182419,035917",
                                "lt": "20200707T182419,035917",
                                "et": "20210707T182419,035934",
                                "pi": "csest2319516495356652035",
                                "st": 0,
                                "ty": 52,
                                "cs": 375
                            },
                            {
                                "rn": "statistics_5001",
                                "rmRes": 4979,
                                "crRes": 4998,
                                "htRet": 2231,
                                "htCre": 6,
                                "htUpd": 5106,
                                "htDel": 0,
                                "lgErr": 4,
                                "lgWrn": 9540,
                                "cseSU": "20200708T005406,868457",
                                "cseUT": "0:30:22",
                                "ctRes": 19,
                                "acpi": [
                                    "acp1028273287565921797"
                                ],
                                "ri": "csest7183147931901019038",
                                "ct": "20200707T182429,156655",
                                "lt": "20200707T182429,156655",
                                "et": "20210707T182429,156672",
                                "pi": "csest2319516495356652035",
                                "st": 0,
                                "ty": 52,
                                "cs": 375
                            },
                            {
                                "rn": "statistics_5002",
                                "rmRes": 4980,
                                "crRes": 4999,
                                "htRet": 2249,
                                "htCre": 6,
                                "htUpd": 5107,
                                "htDel": 0,
                                "lgErr": 4,
                                "lgWrn": 9540,
                                "cseSU": "20200708T005406,868457",
                                "cseUT": "0:30:32",
                                "ctRes": 19,
                                "acpi": [
                                    "acp1028273287565921797"
                                ],
                                "ri": "csest7061487257687262039",
                                "ct": "20200707T182439,240053",
                                "lt": "20200707T182439,240053",
                                "et": "20210707T182439,240067",
                                "pi": "csest2319516495356652035",
                                "st": 0,
                                "ty": 52,
                                "cs": 375
                            },
                            {
                                "rn": "statistics_5003",
                                "rmRes": 4981,
                                "crRes": 5000,
                                "htRet": 2249,
                                "htCre": 6,
                                "htUpd": 5108,
                                "htDel": 0,
                                "lgErr": 4,
                                "lgWrn": 9540,
                                "cseSU": "20200708T005406,868457",
                                "cseUT": "0:30:42",
                                "ctRes": 19,
                                "acpi": [
                                    "acp1028273287565921797"
                                ],
                                "ri": "csest8803525397679550584",
                                "ct": "20200707T182449,360863",
                                "lt": "20200707T182449,360863",
                                "et": "20210707T182449,360893",
                                "pi": "csest2319516495356652035",
                                "st": 0,
                                "ty": 52,
                                "cs": 375
                            },
                            {
                                "rn": "statistics_5004",
                                "rmRes": 4982,
                                "crRes": 5001,
                                "htRet": 2249,
                                "htCre": 6,
                                "htUpd": 5109,
                                "htDel": 0,
                                "lgErr": 4,
                                "lgWrn": 9540,
                                "cseSU": "20200708T005406,868457",
                                "cseUT": "0:30:52",
                                "ctRes": 19,
                                "acpi": [
                                    "acp1028273287565921797"
                                ],
                                "ri": "csest4214835427562517289",
                                "ct": "20200707T182459,466163",
                                "lt": "20200707T182459,466163",
                                "et": "20210707T182459,466188",
                                "pi": "csest2319516495356652035",
                                "st": 0,
                                "ty": 52,
                                "cs": 375
                            },
                            {
                                "rn": "statistics_5005",
                                "rmRes": 4983,
                                "crRes": 5002,
                                "htRet": 2249,
                                "htCre": 6,
                                "htUpd": 5110,
                                "htDel": 0,
                                "lgErr": 4,
                                "lgWrn": 9540,
                                "cseSU": "20200708T005406,868457",
                                "cseUT": "0:31:02",
                                "ctRes": 19,
                                "acpi": [
                                    "acp1028273287565921797"
                                ],
                                "ri": "csest2570218605739078081",
                                "ct": "20200707T182509,546456",
                                "lt": "20200707T182509,546456",
                                "et": "20210707T182509,546470",
                                "pi": "csest2319516495356652035",
                                "st": 0,
                                "ty": 52,
                                "cs": 375
                            },
                            {
                                "rn": "statistics_5006",
                                "rmRes": 4984,
                                "crRes": 5003,
                                "htRet": 2251,
                                "htCre": 6,
                                "htUpd": 5114,
                                "htDel": 0,
                                "lgErr": 4,
                                "lgWrn": 9540,
                                "cseSU": "20200708T005406,868457",
                                "cseUT": "0:31:12",
                                "ctRes": 19,
                                "acpi": [
                                    "acp1028273287565921797"
                                ],
                                "ri": "csest5796550581764529614",
                                "ct": "20200707T182519,813047",
                                "lt": "20200707T182519,813047",
                                "et": "20210707T182519,813074",
                                "pi": "csest2319516495356652035",
                                "st": 0,
                                "ty": 52,
                                "cs": 375
                            }
                        ]
                    }
                ]
            }
        ],
        "m2m:nod": [
            {
                "rn": "cse-node",
                "ni": "cse-node",
                "ri": "nod861042590844046387",
                "ct": "20200609T200336,857603",
                "lt": "20200609T200338,706035",
                "et": "20210609T200336,857686",
                "pi": "id-in",
                "ty": 14,
                "acpi": [
                    "acpDefault"
                ],
                "hcl": "id-in",
                "hael": [
                    "CX677vJit2W"
                ],
                "m2m:bat": [
                    {
                        "mgd": 1006,
                        "dc": "battery",
                        "rn": "battery",
                        "btl": 0,
                        "bts": 6,
                        "ri": "bat2485569212438296813",
                        "ct": "20200609T200337,533813",
                        "lt": "20200707T182518,985643",
                        "et": "20210609T200337,533879",
                        "pi": "nod861042590844046387",
                        "ty": 13,
                        "acpi": [
                            "acpDefault"
                        ]
                    },
                    {
                        "mgd": 1007,
                        "dc": "deviceInfo",
                        "rn": "deviceinfo",
                        "dlb": "| IP:<IP_ADDRESS> MAC:70:85:c2:d2:51:14",
                        "dvnm": "machine",
                        "osv": "Linux 4.4.0-19041-Microsoft x86_64",
                        "syst": "20200707T182519,021760",
                        "ri": "dvi8024400728351037531",
                        "ct": "20200609T200338,113010",
                        "lt": "20200707T182519,033519",
                        "et": "20210609T200338,113079",
                        "pi": "nod861042590844046387",
                        "ty": 13,
                        "dty": "unknown",
                        "mod": "unknown",
                        "man": "unknown",
                        "acpi": [
                            "acpDefault"
                        ]
                    },
                    {
                        "mgd": 1003,
                        "dc": "memory",
                        "rn": "memory",
                        "mma":<PHONE_NUMBER>,
                        "mmt":<PHONE_NUMBER>2,
                        "ri": "mem9051650140950871829",
                        "ct": "20200609T200337,821163",
                        "lt": "20200707T182519,015745",
                        "et": "20210609T200337,821244",
                        "pi": "nod861042590844046387",
                        "ty": 13,
                        "acpi": [
                            "acpDefault"
                        ]
                    }
                ]
            }
        ]
    }
}

whereas http://<IP_ADDRESS>:8081/id-in?rc=4 returns
{
    "m2m:cb": {
        "ri": "id-in",
        "ty": 5,
        "rn": "cse-in",
        "csi": "/id-in",
        "acpi": [
            "acpAdmin"
        ],
        "ct": "20200609T200331,388077",
        "lt": "20200609T202105,236548",
        "et": "20210609T200331,388176",
        "pi": "",
        "rr": false,
        "srt": [
            1,
            2,
            3,
            4,
            5,
            9,
            13,
            14,
            16,
            23,
            28,
            52
        ],
        "csz": [
            "application/json"
        ],
        "srv": [
            "3"
        ],
        "poa": [
            "http://<IP_ADDRESS>:8080"
        ],
        "cst": 1,
        "nl": "nod861042590844046387",
        "m2m:acp": [
            {
                "ri": "acp1028273287565921797",
                "rn": "acp_statistics",
                "ct": "20200609T200338,574776",
                "lt": "20200609T200338,574776",
                "et": "20210609T200338,574845",
                "pi": "id-in",
                "ty": 1,
                "pv": {
                    "acr": [
                        {
                            "acop": 63,
                            "acor": [
                                "CAdmin",
                                "CX677vJit2W"
                            ]
                        }
                    ]
                },
                "pvs": {
                    "acr": [
                        {
                            "acop": 51,
                            "acor": [
                                "CAdmin"
                            ]
                        }
                    ]
                }
            },
            {
                "ty": 1,
                "ri": "acpAdmin",
                "rn": "adminACP",
                "pi": "id-in",
                "pv": {
                    "acr": [
                        {
                            "acor": [
                                "CAdmin"
                            ],
                            "acop": 63
                        }
                    ]
                },
                "pvs": {
                    "acr": [
                        {
                            "acor": [
                                "CAdmin"
                            ],
                            "acop": 55
                        }
                    ]
                },
                "ct": "20200609T200331,455044",
                "lt": "20200609T200331,455044",
                "et": "20210609T200331,455162"
            },
            {
                "ty": 1,
                "ri": "acpDefault",
                "rn": "defaultACP",
                "pi": "id-in",
                "pv": {
                    "acr": [
                        {
                            "acor": [
                                "CDefault",
                                "CAdmin"
                            ],
                            "acop": 63
                        }
                    ]
                },
                "pvs": {
                    "acr": [
                        {
                            "acor": [
                                "CAdmin"
                            ],
                            "acop": 55
                        }
                    ]
                },
                "ct": "20200609T200331,513529",
                "lt": "20200609T200331,513529",
                "et": "20210609T200331,513600"
            }
        ],
        "m2m:ae": [
            {
                "rn": "statistics",
                "api": "ae-statistics",
                "nl": "nod861042590844046387",
                "poa": [
                    "http://<IP_ADDRESS>:8080"
                ],
                "rr": true,
                "srv": [
                    "3",
                    "4"
                ],
                "ri": "CX677vJit2W",
                "ct": "20200609T200338,558810",
                "lt": "20200609T200338,558810",
                "et": "20210609T200338,558877",
                "pi": "id-in",
                "ty": 2,
                "aei": "CX677vJit2W",
                "acpi": [
                    "acp1028273287565921797"
                ],
                "acme:csest": [
                    {
                        "rn": "statistics",
                        "cnd": "acme.statistics",
                        "acpi": [
                            "acp1028273287565921797"
                        ],
                        "mni": 10,
                        "rmRes": 4984,
                        "crRes": 5003,
                        "htRet": 2251,
                        "htCre": 6,
                        "htUpd": 5114,
                        "htDel": 0,
                        "lgErr": 4,
                        "lgWrn": 9540,
                        "cseSU": "20200708T005406,868457",
                        "cseUT": "0:31:12",
                        "ctRes": 19,
                        "ri": "csest2319516495356652035",
                        "ct": "20200609T200338,971435",
                        "lt": "20200707T182519,810517",
                        "et": "20210609T200338,971524",
                        "pi": "CX677vJit2W",
                        "st": 5006,
                        "ty": 28,
                        "cs": 375,
                        "cr": "CX677vJit2W",
                        "cni": 10,
                        "acme:csest": [
                            {
                                "rn": "statistics_4997",
                                "rmRes": 4975,
                                "crRes": 4994,
                                "htRet": 2212,
                                "htCre": 6,
                                "htUpd": 5099,
                                "htDel": 0,
                                "lgErr": 4,
                                "lgWrn": 9540,
                                "cseSU": "20200708T005406,868457",
                                "cseUT": "0:29:41",
                                "ctRes": 19,
                                "acpi": [
                                    "acp1028273287565921797"
                                ],
                                "ri": "csest1794142844999499776",
                                "ct": "20200707T182348,711692",
                                "lt": "20200707T182348,711692",
                                "et": "20210707T182348,711708",
                                "pi": "csest2319516495356652035",
                                "st": 0,
                                "ty": 52,
                                "cs": 375
                            },
                            {
                                "rn": "statistics_4998",
                                "rmRes": 4976,
                                "crRes": 4995,
                                "htRet": 2213,
                                "htCre": 6,
                                "htUpd": 5100,
                                "htDel": 0,
                                "lgErr": 4,
                                "lgWrn": 9540,
                                "cseSU": "20200708T005406,868457",
                                "cseUT": "0:29:51",
                                "ctRes": 19,
                                "acpi": [
                                    "acp1028273287565921797"
                                ],
                                "ri": "csest3357060219620329572",
                                "ct": "20200707T182358,823487",
                                "lt": "20200707T182358,823487",
                                "et": "20210707T182358,823501",
                                "pi": "csest2319516495356652035",
                                "st": 0,
                                "ty": 52,
                                "cs": 375
                            },
                            {
                                "rn": "statistics_4999",
                                "rmRes": 4977,
                                "crRes": 4996,
                                "htRet": 2213,
                                "htCre": 6,
                                "htUpd": 5101,
                                "htDel": 0,
                                "lgErr": 4,
                                "lgWrn": 9540,
                                "cseSU": "20200708T005406,868457",
                                "cseUT": "0:30:02",
                                "ctRes": 19,
                                "acpi": [
                                    "acp1028273287565921797"
                                ],
                                "ri": "csest4226788739776195818",
                                "ct": "20200707T182408,912666",
                                "lt": "20200707T182408,912666",
                                "et": "20210707T182408,912689",
                                "pi": "csest2319516495356652035",
                                "st": 0,
                                "ty": 52,
                                "cs": 375
                            },
                            {
                                "rn": "statistics_5000",
                                "rmRes": 4978,
                                "crRes": 4997,
                                "htRet": 2213,
                                "htCre": 6,
                                "htUpd": 5105,
                                "htDel": 0,
                                "lgErr": 4,
                                "lgWrn": 9540,
                                "cseSU": "20200708T005406,868457",
                                "cseUT": "0:30:12",
                                "ctRes": 19,
                                "acpi": [
                                    "acp1028273287565921797"
                                ],
                                "ri": "csest2267622056735906608",
                                "ct": "20200707T182419,035917",
                                "lt": "20200707T182419,035917",
                                "et": "20210707T182419,035934",
                                "pi": "csest2319516495356652035",
                                "st": 0,
                                "ty": 52,
                                "cs": 375
                            },
                            {
                                "rn": "statistics_5001",
                                "rmRes": 4979,
                                "crRes": 4998,
                                "htRet": 2231,
                                "htCre": 6,
                                "htUpd": 5106,
                                "htDel": 0,
                                "lgErr": 4,
                                "lgWrn": 9540,
                                "cseSU": "20200708T005406,868457",
                                "cseUT": "0:30:22",
                                "ctRes": 19,
                                "acpi": [
                                    "acp1028273287565921797"
                                ],
                                "ri": "csest7183147931901019038",
                                "ct": "20200707T182429,156655",
                                "lt": "20200707T182429,156655",
                                "et": "20210707T182429,156672",
                                "pi": "csest2319516495356652035",
                                "st": 0,
                                "ty": 52,
                                "cs": 375
                            },
                            {
                                "rn": "statistics_5002",
                                "rmRes": 4980,
                                "crRes": 4999,
                                "htRet": 2249,
                                "htCre": 6,
                                "htUpd": 5107,
                                "htDel": 0,
                                "lgErr": 4,
                                "lgWrn": 9540,
                                "cseSU": "20200708T005406,868457",
                                "cseUT": "0:30:32",
                                "ctRes": 19,
                                "acpi": [
                                    "acp1028273287565921797"
                                ],
                                "ri": "csest7061487257687262039",
                                "ct": "20200707T182439,240053",
                                "lt": "20200707T182439,240053",
                                "et": "20210707T182439,240067",
                                "pi": "csest2319516495356652035",
                                "st": 0,
                                "ty": 52,
                                "cs": 375
                            },
                            {
                                "rn": "statistics_5003",
                                "rmRes": 4981,
                                "crRes": 5000,
                                "htRet": 2249,
                                "htCre": 6,
                                "htUpd": 5108,
                                "htDel": 0,
                                "lgErr": 4,
                                "lgWrn": 9540,
                                "cseSU": "20200708T005406,868457",
                                "cseUT": "0:30:42",
                                "ctRes": 19,
                                "acpi": [
                                    "acp1028273287565921797"
                                ],
                                "ri": "csest8803525397679550584",
                                "ct": "20200707T182449,360863",
                                "lt": "20200707T182449,360863",
                                "et": "20210707T182449,360893",
                                "pi": "csest2319516495356652035",
                                "st": 0,
                                "ty": 52,
                                "cs": 375
                            },
                            {
                                "rn": "statistics_5004",
                                "rmRes": 4982,
                                "crRes": 5001,
                                "htRet": 2249,
                                "htCre": 6,
                                "htUpd": 5109,
                                "htDel": 0,
                                "lgErr": 4,
                                "lgWrn": 9540,
                                "cseSU": "20200708T005406,868457",
                                "cseUT": "0:30:52",
                                "ctRes": 19,
                                "acpi": [
                                    "acp1028273287565921797"
                                ],
                                "ri": "csest4214835427562517289",
                                "ct": "20200707T182459,466163",
                                "lt": "20200707T182459,466163",
                                "et": "20210707T182459,466188",
                                "pi": "csest2319516495356652035",
                                "st": 0,
                                "ty": 52,
                                "cs": 375
                            },
                            {
                                "rn": "statistics_5005",
                                "rmRes": 4983,
                                "crRes": 5002,
                                "htRet": 2249,
                                "htCre": 6,
                                "htUpd": 5110,
                                "htDel": 0,
                                "lgErr": 4,
                                "lgWrn": 9540,
                                "cseSU": "20200708T005406,868457",
                                "cseUT": "0:31:02",
                                "ctRes": 19,
                                "acpi": [
                                    "acp1028273287565921797"
                                ],
                                "ri": "csest2570218605739078081",
                                "ct": "20200707T182509,546456",
                                "lt": "20200707T182509,546456",
                                "et": "20210707T182509,546470",
                                "pi": "csest2319516495356652035",
                                "st": 0,
                                "ty": 52,
                                "cs": 375
                            },
                            {
                                "rn": "statistics_5006",
                                "rmRes": 4984,
                                "crRes": 5003,
                                "htRet": 2251,
                                "htCre": 6,
                                "htUpd": 5114,
                                "htDel": 0,
                                "lgErr": 4,
                                "lgWrn": 9540,
                                "cseSU": "20200708T005406,868457",
                                "cseUT": "0:31:12",
                                "ctRes": 19,
                                "acpi": [
                                    "acp1028273287565921797"
                                ],
                                "ri": "csest5796550581764529614",
                                "ct": "20200707T182519,813047",
                                "lt": "20200707T182519,813047",
                                "et": "20210707T182519,813074",
                                "pi": "csest2319516495356652035",
                                "st": 0,
                                "ty": 52,
                                "cs": 375
                            }
                        ]
                    }
                ]
            }
        ],
        "m2m:bat": [
            {
                "mgd": 1006,
                "dc": "battery",
                "rn": "battery",
                "btl": 0,
                "bts": 6,
                "ri": "bat2485569212438296813",
                "ct": "20200609T200337,533813",
                "lt": "20200707T182518,985643",
                "et": "20210609T200337,533879",
                "pi": "nod861042590844046387",
                "ty": 13,
                "acpi": [
                    "acpDefault"
                ]
            },
            {
                "mgd": 1007,
                "dc": "deviceInfo",
                "rn": "deviceinfo",
                "dlb": "| IP:<IP_ADDRESS> MAC:70:85:c2:d2:51:14",
                "dvnm": "machine",
                "osv": "Linux 4.4.0-19041-Microsoft x86_64",
                "syst": "20200707T182519,021760",
                "ri": "dvi8024400728351037531",
                "ct": "20200609T200338,113010",
                "lt": "20200707T182519,033519",
                "et": "20210609T200338,113079",
                "pi": "nod861042590844046387",
                "ty": 13,
                "dty": "unknown",
                "mod": "unknown",
                "man": "unknown",
                "acpi": [
                    "acpDefault"
                ]
            },
            {
                "mgd": 1003,
                "dc": "memory",
                "rn": "memory",
                "mma":<PHONE_NUMBER>,
                "mmt":<PHONE_NUMBER>2,
                "ri": "mem9051650140950871829",
                "ct": "20200609T200337,821163",
                "lt": "20200707T182519,015745",
                "et": "20210609T200337,821244",
                "pi": "nod861042590844046387",
                "ty": 13,
                "acpi": [
                    "acpDefault"
                ]
            }
        ],
        "m2m:nod": [
            {
                "rn": "cse-node",
                "ni": "cse-node",
                "ri": "nod861042590844046387",
                "ct": "20200609T200336,857603",
                "lt": "20200609T200338,706035",
                "et": "20210609T200336,857686",
                "pi": "id-in",
                "ty": 14,
                "acpi": [
                    "acpDefault"
                ],
                "hcl": "id-in",
                "hael": [
                    "CX677vJit2W"
                ]
            }
        ]
    }
}

diff these and you'll see that in the fu=1 response the tree is flattened. i believe this is a bug.

Thanks for reporting this. This should be fixed now.
Sorting the result set at the wrong time messed up the internal structure.

yes, i'm using the development branch. Can you please double check the sheet at https://docs.google.com/spreadsheets/d/1_eQOpghaDnWzYZ672pvBS77yFupSVEuNORSO_qin2mY that shows the different responses for different combinations of the rcn, fu and drt parameters. i'm still not convinced they all match up with what's in the spec, but i find the spec so vague on this still that it's difficult for me to come up with reasons.

Hi,
In fact, rcn=4 should not be used for Discovery operation. That's only valid for Retrieve (normal retrieve) and Delete operation as specified in TS-0001. When valid for Discovery operation it is mentioned explicitly.
Both TS-0001 and TS-0004 will be updated to clarify that.

In fact, rcn=4 should not be used for Discovery operation.

reallly? that directly contradicts what Andreas told me before. and this would seem to be confirmed by this issue & fix: https://github.com/ankraft/ACME-oneM2M-CSE/issues/41

I fact It seems that I was wrong about this. We talked about this issue today and it seems that the respective clause in TS-0004 does in fact not correctly describe what is (only vaguely) specified in TS-0001. I am sorry.

can you please explain the differences between the results for rcn=8 and rcn=8&fu=1:
rcn=8:
{
    "m2m:cb": {
        "m2m:acp": []
        ...

rcn=8&fu=1:
{
    "m2m:acp": []
    ...

i'm really having a hard time working out where in the spec it says that the responses should look like this. Regardless, I cannot see why these results should be different.

When valid for Discovery operation it is mentioned explicitly.

Can you please point me to the place in the spec where the valid Discovery results types are "mentioned explicitly" ?

Hi,
Same case as for rcn=4, that is not valid for Discovery operation. You can find that in TS-0001 8.1.2 where there's only one rcn value (child-resources-references) for which Discovery mechanism can be used. And also TS-0004 7.5.2-2, where only URIList and resourceRefList are possible response content for Discovery operation. Both TS-0001 and TS-0004 will be updated to clarify that. As info, only rcn=6 (child-resources-references) and rcn not present are valid for Discovery operation.

Fantastic, thanks for clearing that up.

so, where in the spec does it say what the format of these responses is supposed to be?
for example, i'm looking at the rcn=8 response, which looks like this:
{
    "cb": {
        "acp": [
            {
               ...

however, this doesn't look right to me, because returning an empty parent resource ( ch in this example) like that would seem to contravene some of the minOccurs requirements in the xsd for some resources. any compliant deserializer is going to reject that as an invalid resource.
i would have expected the response to just contains the child resources, eg:
{
    "acp": [
        {
           ...

... but i cannot find anything in the spec that states which is correct.

All protocol related stuff is in TS-0004, including format of responses. In TS-0004 table 7.5.2-2, you find which element the content response should contain according to the operation/rcn value. In your case, R/8 of the CSEBase will return the CSEBase with only child resources (just as you indicated).
Regarding your question about XSD, in TS-0004 clause <IP_ADDRESS>, you can find that for partial resources (which is the case) , "since a partial resource is being transferred it is not required to be valid according to the XSD for that resource in terms of the presence of resource attributes"


Windows CI: Port TestKill*

Signed-off-by: John Howard<EMAIL_ADDRESS>Ports TestKill* in docker_cli_kill_test.go to Windows CI. Output from a local TP4 run below:
PS E:\go\src\github.com\docker\docker\integration-cli> runtest w TestKill
Running test TestKill
DOCKER_TEST_HOST=tcp://<IP_ADDRESS>:2375
DOCKER_HOST=tcp://<IP_ADDRESS>:2375
=== RUN   Test
INFO: Testing against a local daemon
PASS: docker_cli_kill_test.go:12: DockerSuite.TestKillContainer 24.975s
SKIP: docker_cli_kill_test.go:34: DockerSuite.TestKillDifferentUserContainer (Test requires a Linux daemon)
PASS: docker_cli_kill_test.go:24: DockerSuite.TestKillOffStoppedContainer       12.765s
PASS: docker_cli_kill_test.go:88: DockerSuite.TestKillStoppedContainerAPIPre120 13.230s
PASS: docker_cli_kill_test.go:63: DockerSuite.TestKillWithInvalidSignal 20.531s
SKIP: docker_cli_kill_test.go:49: DockerSuite.TestKillWithSignal (Test requires a Linux daemon)
OK: 4 passed, 2 skipped
--- PASS: Test (88.67s)
PASS
ok      github.com/docker/docker/integration-cli        89.618s
PS E:\go\src\github.com\docker\docker\integration-cli>

And more cuteness :dog2:

LGTM

LGTM

@dug would like the pictures.
Question: I can understand that windows doesn't support SIGWINCH. What does -s 0 and -s 30 end up doing? Windows doesn't have named signals, but there are numbered signals?

huge +1 to the picts - think we need to start a cute-dog-picts-war!  :-)

@MHBauer It's all a trick by golang. They really don't exist. As per the comment in golangs syscall\ztypes_windows.go: // More invented values for signals. Doesn't matter whether named or number.

@duglin - yeah, someone changed the default text on PR submission recently to include a cute animal pic. I think I'm good for at least my next 10,000 PRs :smile:

LGTM
More pictures please!


Commandline option to set initial input

When lighthouse is triggered from another program (for example, sxiv), it would be useful to be able to provide an initial input string.
For example if the the user triggers TMSU tagging via pressing 'h', then lighthouse (the interactive part of this process) could ideally start with the character 'h' already input.
I suppose '-i' would be the logical name for this option.
I am looking at how to implement this but may not have time to do so in the next few days.

The following diff mostly implements this:
The missing functionality is that the results list is not updated until the user starts typing.
index 4ecd9b5..3203802 100644
--- a/README.md
+++ b/README.md
@@ -111,6 +111,8 @@ Options
 The `-c` command line flag will allow you to set a custom location for the configurations file.
 An example would be `lighthouse -c ~/lighthouserc2`.

+The `-i` command line flag allows you to set the initial value of the input line, rather than beginning with a completely empty line.
+
 Configuration file
 ---
 Check out the sample `lighthouserc` in `config/lighthouse`.  Copy it to your directory by
diff --git a/src/lighthouse.c b/src/lighthouse.c
index b0ef08e..c706a21 100644
--- a/src/lighthouse.c
+++ b/src/lighthouse.c
@@ -455,16 +455,20 @@ int main(int argc, char **argv) {
   /* Determine if there is an XDG_CONFIG_HOME to put the config in, otherwise use ~/.config */
   char *config_file_dir = (getenv("XDG_CONFIG_HOME")) ? getenv("XDG_CONFIG_HOME") : "~/.config";
   char *config_file = malloc(strlen(config_file_dir) + strlen(CONFIG_FILE) + 1);
+  char *initial_input = NULL;
   if (!config_file) {
     return 1;
   }
   sprintf(config_file, "%s%s", config_file_dir, CONFIG_FILE);
   int c;
-  while ((c = getopt(argc, argv, "c:")) != -1) {
+  while ((c = getopt(argc, argv, "c:i:")) != -1) {
     switch (c) {
       case 'c':
         config_file = optarg;
         break;
+      case 'i':
+        initial_input = optarg;
+        break;
       default:
         break;
     }
@@ -677,10 +681,15 @@ int main(int argc, char **argv) {

   /* Query string. */
   char query_string[MAX_QUERY];
-  memset(query_string, 0, sizeof(query_string));
   uint32_t query_index = 0;
   uint32_t query_cursor_index = 0;

+  memset(query_string, 0, sizeof(query_string));
+  if (initial_input) {
+    strncpy(query_string, initial_input, MAX_QUERY - 1);
+    query_cursor_index = strlen(query_string);
+    query_index = query_cursor_index;
+  }
   /* Now draw everything. */
   redraw_all(connection, window, cairo_context, cairo_surface, query_string, query_cursor_index);

don't subtract 1 from MAX_QUERY, the null terminator isn't implicitly copied with strncpy

Okay, thanks, I missed that subtlety.


Status Code "301" on searching with gobuster

when using the gobuster it seems show an error.
i'm using the payload below:
./gobuster dir -u https://.. -w ~/node-dirbuster/lists/directory-list-2.3-medium.txt -b "" -k
And the result showing below:
the server returns a status code that matches the provided options for non existing urls. https://../3f75e0e5-dd76-4caf-a937-ed7c56a994bc => 301 (Length: 0). To continue please exclude the status code or the length
im using gobuster v3.4 and golang go1.19.5 (as i assume from previous error came from golang)
if i use the payload  ( -b "301,404" ) it works fine, but i can't see the 301 on the result.
any way to prevent the error?
Thanks

This is no error, it just tells you to configure your gobuster correctly to work with this site. If all urls return a 301 there is no sense in treating those as positive status codes


Explain bridge bind mechanism

What this PR does / why we need it:
This PR adds information about the bridge binding mechanism to the networking dev guide.
Explaining the bridge bind mechanism is a pre-requirement to explain the masquerade bind mechanism, since plenty of the bridge implementation is re-used in that binding mechanism.
Which issue(s) this PR fixes:
Partially Fixes #3333
Special notes for your reviewer:
Depends on #3342
Release note:

NONE

/cc @EdDev @phoracek

First commit: Please not that except my inline comments, the changes that you have added after the previous review have landed on the 2nd commit and not in the first.

Right, the first just separates the 2 concepts. The second commit is where bridge binding is explained.

@davidvossel need a maintainer review here. Thanks in advance !

/retest

/retest

Thank for making the changes.
/lgtm
/approve

/retest

@vladikr could you override the failing lane ? This doc change is pretty harmless.

@vladikr could you override the failing lane ? This doc change is pretty harmless.

Maybe this will help in the future: https://github.com/kubevirt/kubevirt/pull/3457

/retest

/override pull-kubevirt-e2e-kind-k8s-1.17.0-ipv6


Physical equality should be named structural equality?

In my research about Reason was reading up more on OCaml and got confused about the wording.
In OCaml they seem to differentiate between structural and physical equality. The Reason codebase as well as in the Reason docs mention physical and reference equality as two different things while from my understanding they are the same.
Currently the mapping seems like this to me
Physical Equality in OCaml (==) maps to Referential Equality (===) in Reason
Structural Equality in OCaml (=) maps to Physical Equality (==) in Reason
Which results in
Physical equality in OCaml IS NOT phyiscal equality in Reason
Possible Solution
Physical Equality in OCaml (==) maps to Referential Equality (===) in Reason
Structural Equality in OCaml (=) maps to Structural~Physical~ Equality (==) in Reason
Occurrences in Reason Codebase and Docs
Docs mention: https://reasonml.github.io/docs/en/overview.html
ReasonML code: https://github.com/facebook/reason/blob/7b13876edc65b2b1043e86c5c5c13fefb06e65a0/formatTest/typeCheckedTests/input/mlSyntax.ml#L50-L56
Shouldn't this be structural and referential equality?
OCaml Resources
OCaml Cheetsheet - http://www.ocamlpro.com/files/ocaml-lang.pdf
http://www2.lib.uchicago.edu/keith/ocaml-class/operators.html

OCaml distinguishes between structural equality and physical equality (essentially equality of the address of an object). = is structural equality and == is physical equality.

btw happy to contribute a PR

"Physical Equality in OCaml (==) maps to Referential Equality (===) in Reason"
I may be misinterpreting this, but the truth is that Physical Equality in OCaml maps to Physical Equality in Reason. The same for Referential. The only thing that is different is the symbol that we use to reference those concepts. That is likely what you meant, but I thought I would clarify for anyone listening.

Thank you.


文件夾的名稱有不足

复现步骤 / Step to reproduce
原標題

在文件夾上的名字會減少

预期行为 / Expected behaviour
文件夾應該對應標題有完整的名字
实际行为 / Actual Behaviour
在文件夾上的名字會減少

应用日志 / App logs
🐛 init LogUtil success
🐛 init UserSetting success
🐛 init TabBarSetting success: default
🐛 init SiteSetting success
🐛 init FavoriteSetting success
🐛 init EHSetting success, site: EX
🐛 init DownloadSetting success
💡 systemProxyAddress:
🐛 init EHRequest success
🐛 init PreferenceSetting success
💡 Refresh tag translation data
🐛 init TagTranslationService success
💡 Refresh tag order optimization data
🐛 init TagSearchOrderOptimizationService success
🐛 init MouseSetting success: default
🐛 init QuickSearchService success
🐛 init HistoryService success
🐛 init PerformanceSetting success: default
🐛 init SuperResolutionSetting success
🐛 init SuperResolutionService success
🐛 init ReadSetting success
🐛 init LocalBlockRuleService success
🐛 init Gallery groups: [同人, 默認, 單本行, Artist CG, Image Set, Short Manga, Game CG]
🐛 init Archive groups: []
🐛 init ArchiveDownloadService success. Tasks count: 0
🐛 init DownloadService success, download task count: 335
🐛 start download executor
🐛 init SearchHistoryService success
💡 GallerysPageLogic get data, prevGid:null, nextGid:null
💡 refresh FavoriteSetting
💡 refresh SiteSetting
💡 refresh EHSetting
💡 refresh MyTagsSetting
🐛 init VolumeService success
💡 Refresh local gallerys, preCount:0, newCount: 0, timeCost: 438ms
💡 Tag order optimization data is up to date, tag: v2023.12.31-1
💡 refresh EHSetting success
💡 refresh SiteSetting success
💡 refresh default tag set success, length: 54
💡 refresh FavoriteSetting success
💡 search for artist:"otama ryouichi$"
💡 DesktopSearchPageTabLogic get data, prevGid:null, nextGid:null
💡 Get gallery details:https://exhentai.org/g/1992288/bf56a6e424/
✔  Try to find gallery via secondLink: GalleryUrl{isEH: false, gid: 1992288, token: bf56a6e424}
💡 Tag translation data downloaded
💡 Tag translation data is up to date, timestamp: 2024-06-30T17:56:22.000Z
✔  Record history: 1992288
💡 DesktopSearchPageTabLogic get data, prevGid:null, nextGid:null
💡 DesktopSearchPageTabLogic get data, prevGid:null, nextGid:null
💡 DesktopSearchPageTabLogic get data, prevGid:null, nextGid:null
💡 search for artist:"otama ryouichi$"
💡 Get gallery details:https://exhentai.org/g/2679295/e329f966bc/
✔  Try to find gallery via secondLink: GalleryUrl{isEH: false, gid: 2679295, token: e329f966bc}
💡 Begin to download gallery: [Atama Ohanabatake (Otama)] Futatabi Hoshi o Shiru (Fate/stay night) [Chinese] [GOA漢化] [Digital], original: false
✔  Record history: 2679295
✔  cache hit: https://exhentai.org/g/2679295/e329f966bc/?p=0&hc=0
✔  cache hit: https://exhentai.org/g/2679295/e329f966bc/?p=0&hc=0
💡 Get gallery details:https://exhentai.org/g/2961808/4f1a25c8de/
✔  Try to find gallery via secondLink: GalleryUrl{isEH: false, gid: 2961808, token: 4f1a25c8de}
✔  cache hit: https://exhentai.org/g/2679295/e329f966bc/?p=0&hc=0
✔  cache hit: https://exhentai.org/g/2679295/e329f966bc/?p=0&hc=0
💡 Begin to download gallery: [Atama Ohanabatake (Otama Ryouichi)] Akanesasu Sora Tomurai  (Fate/stay night) [Digital], original: false
✔  Record history: 2961808
💡 Get gallery details:https://exhentai.org/g/2961811/e6d36e15ae/
✔  Try to find gallery via secondLink: GalleryUrl{isEH: false, gid: 2961811, token: e6d36e15ae}
✔  cache hit: https://exhentai.org/g/2679295/e329f966bc/?p=0&hc=0
✔  Record history: 2961811
✔  cache hit: https://exhentai.org/g/2679295/e329f966bc/?p=0&hc=0
💡 Begin to download gallery: [Atama Ohanabatake (Otama Ryouichi)] Akanesasu Sora Tomurai  (Fate/stay night) [Digital], original: false
💡 App is hidden
✔  cache hit: https://exhentai.org/g/2679295/e329f966bc/?p=0&hc=0
✔  cache hit: https://exhentai.org/g/2679295/e329f966bc/?p=0&hc=0
✔  cache hit: https://exhentai.org/g/2679295/e329f966bc/?p=0&hc=0
✔  cache hit: https://exhentai.org/g/2679295/e329f966bc/?p=0&hc=0
✔  cache hit: https://exhentai.org/g/2679295/e329f966bc/?p=0&hc=0
💡 App is shown
✔  cache hit: https://exhentai.org/g/2679295/e329f966bc/?p=0&hc=0
✔  cache hit: https://exhentai.org/g/2679295/e329f966bc/?p=0&hc=0
✔  cache hit: https://exhentai.org/g/2679295/e329f966bc/?p=0&hc=0
💡 Get gallery details:https://exhentai.org/g/2609280/fd93acaef9/
✔  Try to find gallery via secondLink: GalleryUrl{isEH: false, gid: 2609280, token: fd93acaef9}
✔  cache hit: https://exhentai.org/g/2679295/e329f966bc/?p=0&hc=0
✔  Record history: 2609280
✔  cache hit: https://exhentai.org/g/2679295/e329f966bc/?p=0&hc=0
💡 Begin to download gallery: (C101) [Atama Ohanabatake (Otama Ryouichi)]  Sono Hi, Shounen wa Hakua no Casino ni Mayoikomu - On the day, the boy wandered into the white casino. 如果您有多个问题报告，烦请发起多个 Issue / Ensure there is only one bug report in this issue. Please make mutiply issue for mutiply bugs
[X] 您确保已使用最新版本测试，并且该问题在最新版本中并未解决 / This bug have not solved in latest version

文件夹名称长度最大为85字符，以避免超出部分系统下的文件夹名称长度限制。


Add BEGIN

Closes #90.
I implemented BEGIN as a binary operator with special handling for the variadic case. This seems clean and minimal.
This contains no tests and no circuit implementation. As discussed with @emmorais, he will add those.
Based on discussion below, I decided to go ahead and add BEGIN1 also, since it's relatively easy and fresh. Even if we can solve in other ways, those will probably be more expensive, and I think this is a fundamental sequencing operator.
Hopefully the examples below clarify the semantics of BEGIN and BEGIN1.
> (begin (emit 1) (emit 2) (emit 3))
1
2
3
[13 iterations] => 3
> (begin1 (emit 1) (emit 2) (emit 3))
1
2
3
[14 iterations] => 1

NOTE: I am reviewing 'my own' PR, since @emmorais has added the circuit work on top of my initial non-circuit implementation. GitHub won't let me make this a 'review', though.

This looks pretty good, with a few comments spread throughout.
Also, we should add a circuit test that (begin) => NIL.

I think lurk-lib needs to be updated to latest master. It currently seems to point to a previous commit. That said, we may want to update the !(:assert-emitted …) test to switch the ordering of arguments as noted above.


Update CI config to latest Rails 7.0 version

@Spone would you be up for bringing this PR back up to date?


removing categoryResource json - test

PR Checklist

[ ] Explain your changes, so people looking at the PR know what and why, the code changes are the how.
[ ] if updating templates, it is helpful to post a screenshot of what the changes look like.
[ ] if updating templates, ensure that your parameters and steps have meaningful names.
[ ] if adding new templates, ensure that your parameters and columns have display names.
[ ] if adding new templates, or changing items in a gallery, it's helpful to post a screenshot of what the gallery looks like now

Removing redundant categoryResources.json file from the sub-folder under Azure Monitor - Workspaces to see if it resolves redundancy of category when viewing from AzMon\Workbooks.

I need to package and upload to my storage blob to test and verify this change I'm testing works.  #please-hold this PR.

@yves-chan - I've adjusted strategy after consideration, aligning the parent folder for the workbooks with Azure Monitor agents instead of LA workspace.  This aligns with how it's positioned in the docs and with the service, including future plans around the agent.  I've tested this locally and it works so I'd like your approval to move forward.  As I add new workbooks/features, it makes it easy to keep contained in this "package". #sign-off

Although this works I still think we should use virtual categories  to solve our folder structure issue

I could be wrong here, but theses workbooks don't necessarily need two different categories because the workbook themselves are related to workspaces.
Can we also set isPreview in the settings.json on the older workbook (or alternatively, we can just have an empty gallery array) to hide it from the gallery)?

Had a quick sync with Matt on teams, in the future there would be a lot of different kinds of Agents, so it makes sense to start making agents it's own category. We've added a deprecated message in the old workbook.
We will add a workbook link inside the old workbook to point users to the new one. This will be done in a different PR


LND sync stuck after upgrade to 1.7.1

Hi,
my lightning synchronization seems to be stuck after upgrade from 1.6.2 to 1.7.1 similar to #2675.

I my case there seems to be a problem with the TLS certificate. This is the repeated output after sudo journalctl -f -u lnd:
Nov 02 10:13:52 raspberrypi systemd[1]: lnd.service: Service RestartSec=1min expired, scheduling restart.
Nov 02 10:13:52 raspberrypi systemd[1]: lnd.service: Scheduled restart job, restart counter is at 1539.
Nov 02 10:13:52 raspberrypi systemd[1]: Stopped LND Lightning Daemon.
Nov 02 10:13:52 raspberrypi systemd[1]: Starting LND Lightning Daemon...
Nov 02 10:13:52 raspberrypi systemd[1]: Started LND Lightning Daemon.
Nov 02 10:13:52 raspberrypi lnd[28433]: unable to load TLS credentials: tls: private key does not match public key
Nov 02 10:13:52 raspberrypi systemd[1]: lnd.service: Main process exited, code=exited, status=1/FAILURE
Nov 02 10:13:52 raspberrypi systemd[1]: lnd.service: Failed with result 'exit-code'.

This is the complete debug: https://www.toptal.com/developers/hastebin/nerugupova.yaml
My LND wallet is empty, so I guess I can just reset it.

Try CONNECT - RESET
to reset the tls.cert instead of starting a new wallet.

Ok that fixed it. Thanks!


[TEST] v1.3.2 Release Testing: Three node upgrade w/ 2 MGMT/Default Nodes & 1 Witness Node

What's the test to develop? Please describe
Three node upgrade w/ 2 MGMT/Default Nodes & 1 Witness Node

Uprade Path [3]: H1.3.1 + R2.8.5 (k1.28) -> H1.3.2 + R2.9.0 (K1.29) -> (K1.30)
OS [1, 2, 3, 7]:

SLES 15 SP6 (sles@ipv4)
SLES 15 SP4 (sles@ipv4)
Ubuntu 24.04 (ubuntu@ipv4)
RHEL 9.4 (cloud-user@ipv4)

Prerequisite and dependency of test

Setup three nodes cluster w/ witness node
VLAN 1 network on mgmt and 1 network on other NICs
2 Virtual machines with data and md5sum computed- 1 running, 1 stopped
2 VM backup, snapshots - 1 backup when VM is running and 1 backup when VM is stooped
Create a new storage class apart from default one. Use the new storage class for some basic operations.
Import to Rancher and create an RKE2 guest cluster provisioned on Harvester VM before the upgrade.
Deploy Harvester cloud provider to RKE1 Cluster (prior to latest version)
Verify DHCP load balancer service
Install Harvester CSI Driver (prior to latest version)
Create a new Harvester PVC for nginx deployment
Upgrade Rancher
Upgrade Harvester

Describe the items of the test development (DoD, definition of done) you'd like

Dependencies Check

dependency_charts
Versions of all the crds

Virtual machines are in same state as before and accessible.
Restore the backups, check the data
Image and volume status
Monitoring chart status
VM operations are highlighted and working fine.
Import Harvester into a Rancher cluster
Add a node after the upgrade
Upgrade the RKE2 guest cluster to 1.27 or above
Upgrade cloud provider and CSI driver
Verify DHCP load balancer service and create a new Harvester PVC
Shutting off VM and then restarting VM

Additional context

Prerequisite and dependency of test

 :green_circle: Setup three nodes v1.3.1 cluster w/ witness node

hosts

node-0

node-1

node-2

 VLAN 1 network on mgmt and 1 network on other NICs

:warning:: Fail due to reason

SCREENSHOT

 Create a new storage class apart from default one. Use the new storage class for some basic operations.

:warning:: Fail due to reason

SCREENSHOT

 4 Virtual machines with data and md5sum computed- 2 running, 2 stopped

:warning:: Fail due to reason

SCREENSHOT

SLES 15 SP6 (sles@ipv4): Running, mgmt-vlan1, extra new-sc disk.
SLES 15 SP4 (sles@ipv4): Stopped, ens5-vlan1
RHEL 9.4 (cloud-user@ipv4), Running, ens5-vlan1
Ubuntu 24.04 (ubuntu@ipv4), Stopped, mgmt-vlan1, extra new-sc disk.

 2 VM backup, snapshots - 1 when VM is running and 1 when VM is stooped

:warning:: Fail due to reason

SCREENSHOT

SLES 15 SP6 (sles@ipv4): Running, mgmt-vlan1
SLES 15 SP4 (sles@ipv4): Stopped, ens5-vlan1
RHEL 9.4 (cloud-user@ipv4), Running, ens5-vlan1
Ubuntu 24.04 (ubuntu@ipv4), Stopped, mgmt-vlan1

 Import to Rancher and create an RKE2 guest cluster provisioned on Harvester VM before the upgrade.

:warning:: Fail due to reason

SCREENSHOT

 Deploy Harvester cloud provider to RKE1 Cluster (prior to latest version)

:warning:: Fail due to reason

SCREENSHOT

 Verify DHCP load balancer service

:warning:: Fail due to reason

SCREENSHOT

 Install Harvester CSI Driver (prior to latest version)

:warning:: Fail due to reason

SCREENSHOT

 Create a new Harvester PVC for nginx deployment

:warning:: Fail due to reason

SCREENSHOT

 Upgrade Rancher

:warning:: Fail due to reason

SCREENSHOT

 Upgrade Harvester

:warning:: Fail due to reason

SCREENSHOT

Upgrade to harvester-v1.3.1 to harvester-v1.3.2-rc2

 :green_circle: Prepare an airgapped upgrade

Ref. https://docs.harvesterhci.io/v1.3/upgrade/index/#prepare-an-air-gapped-upgrade

 :green_circle: Trigger Upgrade

 Successfully upgrade

:warning:: Fail due to reason

SCREENSHOT

Post-upgrade Checks

Dependencies Check
Chart: https://github.com/harvester/harvester/tree/v1.3/deploy/charts/harvester/dependency_charts
Values: https://github.com/harvester/harvester/blob/v1.3/deploy/charts/harvester/values.yaml

 :green_circle: csi-snapshotter

 :green_circle: kubevirt-operator

 :green_circle: kubevirt

 :green_circle: snapshot-validation-webhook

 :green_circle: whereabouts

Check dependency_charts version
https://github.com/harvester/harvester/tree/v1.3/deploy/charts/harvester-crd/templates

 :green_circle: csi-snapshotter

volumesnapshotclasses

volumesnapshotcontents

volumesnapshots

 :green_circle: kubevirt-operator

 :green_circle: whereabouts

whereabouts.cni.cncf.io_ippools

whereabouts.cni.cncf.io_overlappingrangeipreservations

Check harvester_crd version
https://github.com/harvester/harvester/tree/v1.3/deploy/charts/harvester-crd/templates

 :green_circle: harvesterhci.io_addons.yaml

 :green_circle: harvesterhci.io_keypairs.yaml

 :green_circle: harvesterhci.io_preferences.yaml

 :green_circle: harvesterhci.io_settings.yaml

 :green_circle: harvesterhci.io_supportbundles.yaml

 :green_circle: harvesterhci.io_upgradelogs.yaml

 :green_circle: harvesterhci.io_upgrades.yaml

 :green_circle: harvesterhci.io_versions.yaml

 :green_circle: harvesterhci.io_virtualmachinebackups.yaml

 :green_circle: harvesterhci.io_virtualmachineimages.yaml

 :green_circle: harvesterhci.io_virtualmachinerestores.yaml

 :green_circle: harvesterhci.io_virtualmachinetemplates.yaml

 :green_circle: harvesterhci.io_virtualmachinetemplateversions.yaml

Virtual machines are in same state as before and accessible.

Restore the backups, check the data

Image and volume status

Monitoring chart status

VM operations are highlighted and working fine.

Import Harvester into a Rancher cluster

Add a node after the upgrade

Upgrade the RKE2 guest cluster to 1.27 or above

Upgrade cloud provider and CSI driver

Verify DHCP load balancer service and create a new Harvester PVC

Shutting off VM and then restarting VM


Premium API docs not rendering with redocly preview-docs in CLI v1.23.0 and higher

Describe the bug
The redocly preview-docs command does not render premium Redocly API docs starting from Redocly CLI version 1.23.0 despite being logged in with an API key via the redocly login command. Instead, it renders Redoc.
https://github.com/user-attachments/assets/7c890e4b-a0f2-4e0c-bd09-601e3344621d
To Reproduce

Update to the latest version of the Redocly CLI.
Log in using an API key from Redocly Workflows.
Run redocly preview-docs on an OpenAPI file.
Observe the issue.

Expected behavior
Premium Redocly API docs should render when using the redocly preview-docs command while logged in with an API key.
Redocly Version(s)
Redocly CLI v1.25.5
Node.js Version(s)
Node v22.9.0
OS, environment
macOS Sonoma 14.4.1

Fixed: #1805


Added Korean Translation

Added Korean Translation

you should checkout why this is failing you created now multiple times a pr with the sme data without any changes the error clearly points out that you have to remove the comments from your json file to pass the check

It's currently failing, but not due to this PR. Will look into this.

@MichMich This will happen every once in awhile when Travis runs tests. It will fail the build because Git throws back an error while attempting to fetch the pull request.


ReadMe中的PR图重复了

建议只保留一个

Thank you. I already fix it on readme.md.

Thank you. I already fixed it on readme.md.

建议只保留一个

Thank you. I already fixed it on readme.md. @hl0737


Text wrapping issue in typst - long lines of text are not automatically wrapped.

Description
When a line of text is too long, the pdf compiled by typst does not split it, resulting in the line exceeding the page boundaries when displayed.
Reproduction URL
https://typst.app/project/pj9n7Xn8-UvijRkmjKcVGV
Operating system
macOS
Typst version

[X] I am using the latest version of Typst

Failed to initialize: You do not have sufficient permissions to access this project.

The posted reproduction is not a share link and can only be opened by the owner.
Duplicate of https://github.com/typst/typst/issues/674


chore: remove FsVault

What this PR changes/adds
Removes the FsVault
Why it does that
It was inconsistent, and maintaining it was not worth the effort. We have an easy-to-use OSS alternative (Hashicorp), and an in-mem variant for testing.
Further notes
List other areas of code that have changed but are not necessarily linked to the main feature. This could be method
signature changes, package declarations, bugs that were encountered and were fixed inline, etc.
Linked Issue(s)
Closes # <-- insert Issue number if one exists
Please be sure to take a look at the contributing guidelines and our etiquette for pull requests.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 67.34%. Comparing base (7f20ba5) to head (5e46025).
Report is 267 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4202      +/-   ##
==========================================
- Coverage   71.74%   67.34%   -4.41%
==========================================
  Files         919     1010      +91
  Lines       18457    20544    +2087
  Branches     1037     1154     +117
==========================================
+ Hits        13242    13835     +593
- Misses       4756     6236    +1480
- Partials      459      473      +14

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


Add test coverage enforcement to JaCoCo plugin

This commit adds optional configuration to the Jacoco plugin that allows
users to enforce minimum code coverage. For example,
jacoco {
    threshold 0.5
    threshold 0.3, LINE
}

requires every type (e.g., line, class, instructions, etc) of Jacoco coverage
to be above 50% and line coverage to be at least 30%.
Note that this functionality relies on the XML report being enabled.

Related feature request: https://issues.gradle.org/browse/GRADLE-2783

@uschi2000 thanks for the PR. I think we may want a slightly different DSL for specifying the coverage limits. I'm going to open it up for discussion on the gradle-dev-forum to nail down what it should look like. We can then re-work this PR and hopefully we can get this in to the 2.7 release.

Hej @adrianbk , thanks for taking a look. Over the past 1-2 months we have altered both implementation and DSL a little as a result of our experience with this functionality; the most recent version of the plugin is here: https://github.com/palantir/gradle-jacoco-coverage
While this works great as a separate plugin (wrapping the vanilla jacoco plugin), I'd still be keen to get this functionality into Gradle proper.
When discussing the DSL, please refer to the status quo by the examples in https://github.com/palantir/gradle-jacoco-coverage rather than this pull request, thanks!

Thanks @uschi2000. We are interested in adding some similar functionality to Gradle.
I think the best plan to move this forward would be to close this outdated pull request, and start a discussion on the Gradle development list. The most important thing to lock down would be a proposed DSL: once that's agreed on the implementation should be relatively straightforward.

Cheers, @bigdaz .

We've had some detailed internal discussions about this, and @adrianbk was going to bring it up on the development list. Feel free to kick it off, though.
The big question is whether we are simply providing a DSL to configure JaCoCo, or if we do some deeper modelling of the coverage domain and end up with a less 'jacoco-centric' DSL.
The latter is preferable, but a lot more work in the design phase.

Closing this. Adrian Kelly reignited the discussion on the dev list.

Hej @bigdaz, where can I find the dev list, could you send me a link to the discussion?
Thanks! R.

@uschi2000 https://groups.google.com/forum/#!topic/gradle-dev/yIQNTFYvQh4 It's the original post you authored.


@nhardy optional chaining is supported. If you have a sample that doesnt work please open another issue with it to track it separately.

Originally posted by @sheetalkamat in https://github.com/microsoft/TypeScript-TmLanguage/issues/522#issuecomment-549491582

@nhardy optional chaining is supported. If you have a sample that doesnt work please open another issue with it to track it separately.

Turns out optional chain doesn't work. 🙂
declare let foo: Foo | undefined;

foo && foo.bar && foo.bar.baz;

interface Foo {
    bar?: {
        baz?: string;
    }
}

?. here has scope as punctuation.accessor.optional.ts I think it needs to be operator and that's the part missing ?

Potentally - what exactly is the scope as .?

punctuation.accessor.ts and that was why ?. had similar scope


"this" not reflecting inheritance for static methods

From @benjaminmillhouse on February 15, 2018 15:8

VSCode Version: 1.20.1
OS Version: OSX 10.13.3

Steps to Reproduce:

Create a class with a static method on it that returns "this"
Create a class that inherits from the previous class
Check the IntelliSense on the inherited class when calling the static method
3a. IntelliSense shows the returned value as the base class rather than the inherited class
3b. When following this same flow for an instance method IntelliSense correctly shows the returned
value as the inherited class

Does this issue occur when all extensions are disabled?: Yes
Copied from original issue: Microsoft/vscode#43764

From @andy-ms on February 15, 2018 15:44
class C {
    static m() {
        return this;
    }
}
class D extends C {
    static n() {}
}
D.m().n(); // Works at runtime, fails in TS

From @egamma on February 15, 2018 15:39
@benjaminmillhouse please provide a snippet that illustrates the problem and also mention what language you are using when the problem happens.

From @benjaminmillhouse on February 15, 2018 15:47
Sorry - the language is JavaScript.
Here is some example code:
class SomeClass {
    static returnThis() { return this; }
    returnThis() { return this; }
}

class SomeOtherClass { }

SomeClass.returnThis() // IntelliSense detects the returned type as the SomeClass constructor
SomeOtherClass.returnThis() // IntelliSense still detects the returned type as the SomeClass constructor

new SomeClass().returnThis() // IntelliSense detects the returned type as a SomeClass instance
new SomeOtherClass().returnThis() // IntelliSense detects the returned type as a SomeOtherClass instance

Duplicate of https://github.com/Microsoft/TypeScript/issues/5863

Thanks @mhegazy! Agreed. Closing as duplicate


Add end-to-end template rendering tests

Something like sbt testExamples to render all the template files in a given folder, then comparing the result with another file containing the expected output. Then sbt genExamples to regenerate the expected outputs.

added in 24b051c


Support the abstract keyword

At present, any appearance of the abstract keyword causes a missing semicolon lint error on that line.

Just to confirm, this is TS 1.6 syntax, right?

Yes. It's in the master branch of TS (and used inside the compiler) already.

blocked on #474

Fixed on v2.5.0-dev.1. We should add regression tests though.

Hi,
found this issue via google. We are getting tslint warning "missing semicolon" on abstract keywords as well. We are using Visual Studio 2013, TypeScript is version 1.7, and tslint version is the one shipped with "web essentials" - should be newer than August 2015 when this issue was closed I guess...
We are also getting "expected an assignment or function call" warning on the abstract class.
On a method:

On a class:

These are the warnings:

What should we do?


TimeoutOverflowWarning on Upload

Hi,
I'm trying to upload a movie that have more than 300MB size and here is my code:
const fs = require('fs');
const path = require('path');
const accessToken = 'MY TOKEN IS HERE'
const db = require('dropbox-stream');

const FILETOUPLOAD = '/path/to/movie.flv';

let up = db.createDropboxUploadStream({
    token: accessToken,
    filepath: '/test/' + path.basename(FILETOUPLOAD),
    chunkSize: 1000 * 1024,
    autorename: true
  })
  .on('done', res => console.log('Success', res))
  .on('progress', res => console.log(res))
  .on('error', err => console.log(err))

fs.createReadStream(FILETOUPLOAD).pipe(up);

However my console fills in this message:
(node:16533) TimeoutOverflowWarning:<PHONE_NUMBER>000 does not fit into a 32-bit signed integer.
Timer duration was truncated to<PHONE_NUMBER>.
34603008

As you can see here:

The upload process failed and here is the end of the console:
(node:16533) TimeoutOverflowWarning:<PHONE_NUMBER>000 does not fit into a 32-bit signed integer.
Timer duration was truncated to<PHONE_NUMBER>.
309329920
_http_outgoing.js:506
    throw new errors.TypeError('ERR_INVALID_CHAR', 'header content', name);
    ^

TypeError [ERR_INVALID_CHAR]: Invalid character in header content ["Dropbox-API-Arg"]
    at validateHeader (_http_outgoing.js:506:11)
    at ClientRequest.setHeader (_http_outgoing.js:510:3)
    at new ClientRequest (_http_client.js:173:14)
    at Object.request (https.js:245:10)
    at Req._send (/path/to/app/node_modules/hyperquest/index.js:137:21)
    at /path/to/app/node_modules/hyperquest/index.js:51:21
    at process._tickCallback (internal/process/next_tick.js:150:11)

Can you please tell me how to solve this?
All the best,
Mohammed

The video name was in Arabic language and contained "+18" characters, after renaming it to small letter English name it uploaded successfully but this message:
(node:16533) TimeoutOverflowWarning:<PHONE_NUMBER>000 does not fit into a 32-bit signed integer.
Timer duration was truncated to<PHONE_NUMBER>.

Still appear and fill my console.

I'll check with the characters. Seem like a bug. About the timeout message, please update all the nodejs and dependecies to the latest and check if it will happen again.
Thank you

Hi @velocityzen
Thank you for the reply.
I've updated everything and restarted my computer and the issue still there.
Here my system info:
OS: Linux Mint 18.2 Cinnamon
Node: v9.3.0
npm: 5.6.0

I don't have any other dependency in my test project, just "dropbox-stream".
Regards

I just created a test server on Linode and updated everything to the latest versions and the issue appear there.
If you want to take a look at the server just give me your email address or tell me how can I send the root server credentials to you and I'll do with my pleasure.

Fixed all in 1.1.0. Please update

@velocityzen Thank you so much, you are awesome!


FPS capped to 60 as if nothing has changed

My Bloxstrap could not unlock the FPS,although the amount I set should be above it.
I tried to make the limit lower or higher,writing JSON file by myself instead of editing in bloxstrap,I even shut it down and just run RobloxplayerLaucher with rbxfpsunlocker.
I heard my friends‘ could still work,so there must be something wrong with my Roblox or Bloxstrap.What should I do?

My laptop hardware performance is good enough.
The FastFlag used to work and the problem just happened a few days ago till now.


Publish sortable on npm

It looks like the library already supports several module definitions. Adding sortable to npm would allow us to require it as a module and to bundle it with browserify.
// ES2015
import Sortable from 'sortable'

// CommonJS
var Sortable  = require('sortable')

npm would be the perfect place for sortable. Publishing it shouldn't be much work.
As the name is already taken, I would recommend to add a scope.
Thanks

+1

+1
Had to download via npm install git+https://github.com/.... and then hardcore the path in import.


Feat: implement in file replacement as part of the templating process

📲 What
A description of the change.

🤔 Why
Why it's needed, background context.
🛠 How
More in-depth discussion of the change or implementation.
👀 Evidence
Screenshots / external resources / links / etc.
Link to documentation updated with changes impacted in the PR
🕵 How to test
Notes for QA
✅ Acceptance criteria Checklist

[ ] Code peer reviewed?
[ ] Documentation has been updated to reflect the changes?
[ ] Passing all automated tests, including a successful deployment?
[ ] Passing any exploratory testing?
[ ] Rebased/merged with latest changes from development and re-tested?
[ ] Meeting the Coding Standards?

@dnitsch resolve the conflicts and let me know


Pattern: simple overview band design

Wonil-Suh1 created the following on Aug 06:
User story
As a user of IBM.com, I need a way to take a high level overview of the content/product presented on the page that I am looking at.
Potential tasks:

[ ] Review existing designs from (STUF, NUT, Watson)
[ ] Connect with adopters (Web Simplification & Product Pages) to validate the existing designs

Acceptance criteria

[ ] Band design is reviewed and approved by DGC design leadership

Original issue: https://github.ibm.com/webstandards/digital-design/issues/1397

On Sep 25, Wonil-Suh1 commented:
The latest Sketch
@larahanlon @Olivia-Flory @chsanche @spbokma please take a look and comment when you have time.

On Sep 27, Wonil-Suh1 commented:
Specs are being produced. Closing this issue.


Surface pins FE

As a user on the Doorway public site,
I want to see an indication of all the properties that are on Doorway on the map,
So that I understand the full breadth of the listings on the site regardless of what page I'm on.
Note:

Design / Eng are working iteratively on this to solve design issues as dev happens
Perf testing to happen in a different ticket

Short term goals for this:

Incorporate Feedback from LH on accessible patterns for maps
Prepare for a demo (likely in a local dev) to Doorway

Overall AC:

Surface all pins on map
Implement design improvements

QA Notes
This PR updates the map experience to show all pins, not just the pins in the list.
To accommodate this ask and maintain UX, it also adds the following:

Map clustering of pins

Filtering the list view based on what is visible in the map

A new mobile view that toggles between list and map vs the old mobile drawer

A full screen experience of map navigating on both desktop and mobile

Ensure that as you pan around the map and filter, that the map and list reflect the listings you would expect

There is no design. This has been through a prelim design review w Em and will go through another after merge when design can play around w it.


import file in media library:  null reference exception error in server but not in local

hi all,
I use Media Picker in my ck html editor for uploading files.
it was working fine, but now I get null reference error when clicking the import button,
I should mention that when I run project locally it works fine again.
[NullReferenceException: Object reference not set to an instance of an object.]    Orchard.UI.Navigation.NavigationHelper.SetSelectedPath(IEnumerable1 menuItems, HttpRequestBase currentRequest, RouteValueDictionary currentRouteData, Boolean compareUrls) in \Orchard\UI\Navigation\NavigationHelper.cs:116
Orchard.UI.Navigation.NavigationHelper.SetSelectedPath(IEnumerable1 menuItems, HttpRequestBase currentRequest, RouteValueDictionary currentRouteData, Boolean compareUrls) in \Orchard\UI\Navigation\NavigationHelper.cs:100    Orchard.UI.Navigation.NavigationHelper.SetSelectedPath(IEnumerable1 menuItems, HttpRequestBase currentRequest, RouteValueDictionary currentRouteData) in \Orchard\UI\Navigation\NavigationHelper.cs:84
`

I forgot to add orchard version :
my project orchard version is 1.10

In above picture when I click Import button or Create New Folder button , null reference exception appeared !

We fixed some bugs in this class (NavigationHelper) that will probably fix this. Can you try the newest releases? They are minor releases and should be very easy to update.


[ignore: user error] ActionController::InvalidAuthenticityToken after loading session from memory (remember feature)

It appears that session[:_csrf_token] is not set in the session in this case. This causes it to be lazily set on each check of the submitted token but because it is generated after the token used in the form, it does not match.
On a page load after session restore (i.e. delete the session cookie, but leave the remember cookie):
>> session.to_h
=> {"account_id"=>"9dd41226-d110-4b13-b6de-c8d6b09d441f", "active_session_id"=>"XSrfiUyX_MYIatmN1HyJMglgwFHOQOUR0EmWfi14fY4", "authenticated_by"=>["remember"], "two_factor_auth_setup"=>false

I have confirmed that session[:_csrf_token] is set after the failed token (on the server side only, though) and is different on every occurrence.
rails_controller_instance.send(:real_csrf_token, session) is also different between requests, because the real token is not being stored in the session.

(Whoops I didn't intend to submit that issue yet as I am still spelunking around...)
What confuses me is that simply fetching the token (i.e. to render into the form) should be setting it in the session:
>> session.to_h
=> {"account_id"=>"9dd41226-d110-4b13-b6de-c8d6b09d441f", "active_session_id"=>"VeC4l-xoqRfB90HhUjMgitrnn9zIt3vMU475OsSoiVI", "authenticated_by"=>["remember"], "two_factor_auth_setup"=>false}
>> rails_csrf_token
=> "1G7iFBLwiBTqAUV7h8oBuCFH/iBzbEy+3oA51yS/s0eUgW8GB0GjBi7SyPBMVsJArnsrL+RpOtKZMTbcwW/e1Q=="
>> session.to_h
=> {"account_id"=>"9dd41226-d110-4b13-b6de-c8d6b09d441f", "active_session_id"=>"VeC4l-xoqRfB90HhUjMgitrnn9zIt3vMU475OsSoiVI", "authenticated_by"=>["remember"], "two_factor_auth_setup"=>false, "_csrf_token"=>"Lq6wUavZO0xdKgX5tZrs/Fk12taoeKxvozS6U0podE4="}

I have an inkling that perhaps this is happening in the view layer with a copy of the session instead of the one which the session middleware can see and send back to the user.
Inspecting the session before and after the form is renders shows that _csrf_token is in the session:

and yet, if I add a before_rodauth block to inspect the request.session BEFORE authenticity token verification can mutate the session, the key is absent and after authenticity token verification, the key is present but different than the one that should be in the session:
=> {"account_id"=>"9dd41226-d110-4b13-b6de-c8d6b09d441f", "active_session_id"=>"ATTz8uBbrX3tY5PfdBu2eSVzScqqz0w0X4wD80pRk9Q", "authenticated_by"=>["remember"], "_csrf_token"=>"N1JemnFSB0q+5DGNl8bwHrR/b4sRBkOZdkbGShL2aqI="}

OK another thing I noticed is that session["active_session_id"] is also changing each request (which it does NOT when logged in via password.
I am guessing the load_memory thing is constantly replacing the session on each request with a fresh one constructed based on the remember token. :\
I'm not as sure now if this is a rodauth defect or intentional behaviour which is reasonable in that context but doesn't work here so needs to be mitigated by rodauth-rails.
What do you think @jeremyevans @janko ?

OK OK this is all my bad.
I have multiple configurations but I had NOT overridden remember_cookie_key to be different in each case.
I haven't exactly determined how this results in the behaviour I am experiencing to be honest (I'd expect it would just log me in with both configurations for that underlying account, as they use the same tables), but setting remember_cookie_key on either one to be different than the other DOES appear to fix my issue.
Sorry for any time wasted!

It would be a backwards incompatible change, but it might make sense to incorporate the name of the configuration into any session or cookie keys for the default values @jeremyevans. WDYT?

It's not possible for the cookie key to be different.  Theoretically, we could make the session keys prefixed with the rodauth configuration name, but you are correct that it would break backwards compatibility, and I'm not sure it's worth it.  Maybe we can add something like session_key_prefix which would allow you to change the default values for all session keys to prefix them with a string?

It's not possible for the cookie key to be different.

I'm not sure I understand what you are saying here. I was able to change the remember_cookie_key. Or do you mean to change the default (because of backwards compat)?

setting remember_cookie_key on either one to be different than the other DOES appear to fix my issue.

It may have also been the change to session keys that did this, although keeping the remember cookie separate is also necessary for the ultimate desired behaviour (i.e. being able to remember one login but not the other).
Thanks to you both for jeremyevans/rodauth#121 while I slept! :pray: :pray: :pray:


Updated to black version 22.3.0

After clicked 8.1.0 is released it's necessary to update black to prevent exception on run.

Is there any updates?

Sorry about this, somehow I missed this PR!


Add diagnostic for 20GiB COPY Docker bug on Windows

I have Docker desktop 3.2.2 that includes 20.10.5 Docker Engine and it fails to pass this diagnostic. I haven't tried yet to build Docker from master (and not sure how I install it afterwards).

@slonopotamus thanks for implementing this!


Closes #1409

fix: align the source of "identity" in User struct in the various methods with delivery service ClientInfo struct

@Firefly35 You flagged this for review, but the CI is not passing yet

Indeed, but I don't get what is going wrong about format check ?

This will have to be rebased on #1413 for the tests to pass.

Rebase is made.

Sure I will do


Bolt seems to have lost memory of my chat over the last 36 hours.

Describe the bug
Hi I was promoting and the application suddenly crashed and it seemed to have lost my chat history of application. It seemed to have restored to  a point 2 days ago. Is there anyway for me to get the chat history back?
Link to the Bolt URL that caused the error
https://bolt.new/~/sb1-rrjdsl
Steps to reproduce
No specific steps, the application suddenly crashed at 8:19 am EST
Expected behavior
Should've resolved the errors I had in my application.
Screen Recording / Screenshot
No response
Platform
Browser name = Chrome
Full version = <IP_ADDRESS>
Major version = 130
navigator.appName = Netscape
navigator.userAgent = Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36 Edg/<IP_ADDRESS>
performance.memory = {
  "totalJSHeapSize": 48654488,
  "usedJSHeapSize": 45812104,
  "jsHeapSizeLimit":<PHONE_NUMBER>
}
Username = adilharis2001
Chat ID = 65e60438bf67

Additional context
No response

Hey Brian,
I do not see my project on the stackblitz.com. I recently lost all my work
again when my laptop suddenly restarted and Bolt doesn't seem to have
created a backup since yesterday.
Is there any solution for me to retain my chat history and work from today?
Best,
Adil
On Thu, 14 Nov 2024 at 09:24, Brian @.***> wrote:

Hi @adilharis2001 https://github.com/adilharis2001,
Appreciate the feedback! If you are logged into Bolt and have the current
chat you are working in open, can you hover over the left-hand side of the
page to bring up the options menu, click Settings, then click Backups. Are
you able to see a more recent version of your project state there that you
can load?
Alternatively, if you go to stackblitz.com, login (same credentials as
Bolt), click Collections on the left-hand side the page, and then open Bolt
Collection, do you see your project here?
—
Reply to this email directly, view it on GitHub
https://github.com/stackblitz/bolt.new/issues/2314#issuecomment-2476486685,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACNXD5AY34PF4Q4B7BKDNM32ASXDDAVCNFSM6AAAAABRY4S526VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZWGQ4DMNRYGU
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hi @adilharis2001
Sorry to hear about this and understand that this is frustrating. As stability improvements continue to be made, I would do the following:

As you develop your project, frequently make use of the download button in the top right of the page to save a backup.

Periodically open your project in StackBlitz to have a version there that you can continue to develop.

Look for your project in the Bolt Collection as described above. I understand this didn't work prior, but worth checking again going forward as stability improvements are made. Ideally, changes made in Bolt will be reflected in the project in Bolt Collection. Then, you could open the project in the Bolt Collection and continue development in StackBlitz. If you then re-opened the project in Bolt those changes would be reflected.

We really appreciate your patience as the team continues to make improvements! Overall tighter integration with GitHub is being tracked here: #2367, which should help with many of these issues.


Jnthnvctr patch 1

Not merging because it seems like theres merge conflicts for the images for htese speakers? see the other open prs


The hive and the cells: infrastructure for modular applications

This PR introduces the hive and the cells. Hive is an application consisting of a set cells, each of which has an optional configuration and some set of constructors and objects.
Or to put it more concretely, this PR introduces a wrapper around the uber/fx library that extends it to provide the building blocks for building applications out of modular pieces which have their own command-line flags. It aims to allow us to split up DaemonConfig into feature-specific config structs and to allow constructing a custom cilium-agent from potentially out-of-tree modules that extend the functionality, all without having to patch the original source-code.
We'll still of course have some base configuration common to many modules, so some modules may need to depend on multiple config structs.
The cryptic names are to avoid confusion with fx.App (which Hive kind of is) and fx.Module (which Cell kind of is). Plus, they're cute puns on the familiar themes at Isovalent: bees and cilium. I felt it was better to not overload fx terms, but rather have distinct names. Though if you can think of better names or a simpler approach I'm all ears.
Why is this needed? I originally wanted to make configuration flag registration just another fx.Option, but this leads to the situation where command-line flag registration and parsing has to be done when constructing the object graph. This works if the binary only has one command, but we have binaries that have many sub-commands. The concrete one that broke the original approach was "cilium/cmd/preflight.go" that needed to use the K8s client. So to fix this I needed to separate the command-line flags from the uber/fx options, and hence the wrapping of the options into Cell that also includes information about the configuration flags.
A trivial example of an application written with the hive looks like this:
type BrushConfig struct {
  Color string
}
func (BrushConfig) CellFlags(flags *pflag.FlagSet) {
  flag.String("color", "blue", "brush color")
}
type Brush struct { /* ... */ }

func newBrush(cfg BrushConfig) *Brush { /* ... */ }

var BrushCell = hive.NewCellWithConfig[BrushConfig](
  "brush",
  fx.Provide(newBrush),
)
// ---
type PainterConfig { /* ... */ }
func newPainter(cfg PainterConfig, brush *Brush) *Painter { /* ... */ }

var PainterCell = hive.NewCellWithConfig[PainterConfig](
  "painter",
  fx.Provide(newPainter),
)

// ---

func main() {
  hive := hive.New(
    viper.GetViper(), // Viper to populate configs from
    pflag.CommandLine, // FlagSet to which to add the flags

    BrushCell,
    PainterCell,
    // etc.
  )

  pflag.Parse()
  viper.ReadInConfig()

  hive.Run()
}

Also see pkg/hive/example for a runnable example.
Within the cell one uses uber/fx normally, e.g. fx.Provide for constructors and so on. Hive/Cells just provide the means to bubble up the command-line flags without actually constructing the object graph. And perhaps we'll find other things we need to add in the future that need to be outside of uber/fx object graph.
Finally, the reason why flag accumulation isn't done via a global singleton is that we may have binaries that have many commands (and hence flagsets), or test binaries that construct multiple different applications hives with different flags, so one big bag of flags doesn't work.

/test

/test

Failure in test-1.16-4.9 unrelated as the K8sVerifier job is not related to the cilium-agent.