Microsoft.CostManagement/exports@2021-10-01 not idempotent

Bicep version
Bicep CLI version 0.4.1318 (ee0d808f35)
Describe the bug
The API is not idempotent. You can create the resource the first time but when trying to reapply you get:
Status Message: Etag value required for update operation of report: test1.Please get the latest to avoid overwrite. (Request ID: 37dfcd1f-b755-45a0-bcd4-80eb27347b73) (Code:400)
if you try to add
etag: '*'

at the same level as name you will get error:

Error: Code=InvalidRequestContent; Message=The request content was invalid and could not be deserialized: 'Could not find member 'eTag' on object of type 'TemplateResource'. Path 'properties.template.resources[0].eTag', line 19, position 17.'.

To Reproduce
Steps to reproduce the behavior:
targetScope = 'subscription'

resource export 'Microsoft.CostManagement/exports@2021-10-01' = {
  name: 'test1'
  properties: {
    format: 'Csv'
    partitionData: false
    definition: {
      type: 'Usage'
      timeframe: 'TheLastBillingMonth'
      dataSet: {
        granularity: 'Daily'
        configuration: null
      }
      timePeriod: null
    }
    deliveryInfo: {
      destination: {
        resourceId: '/subscriptions/<sub id>/resourceGroups/<rg name>/providers/Microsoft.Storage/storageAccounts/<str account name>'
        container: 'test'
        rootFolderPath: 'test2'
        sasToken: null
        storageAccount: null
      }
    }
    schedule: {
      status: 'Active'
      recurrence: 'Monthly'
      recurrencePeriod: {
        from: '2022-04-06T00:00:00Z'
        to: '2022-05-01T00:00:00Z'
      }
    }
  }
}

Additional context
Add any other context about the problem here.

I am confirming that idempotency is fixed in Microsoft.CostManagement/exports@2022-10-01 but Microsoft.CostManagement/views@2022-10-01 reported by another user still requires eTag thus still not ARM/Bicep Template compliant resource.

I will make a fair comment here that Cost Management team cannot write proper APIs. Even some of the newer and simple APIs like providers/Microsoft.CostManagement/settings do not work properly with ARM/Bicep Templates

Hi, does the issue with Microsoft.CostManagement/views endpoint was resolved? Currently I'm facing this issue.

Hi, does the issue with Microsoft.CostManagement/views endpoint was resolved? Currently I'm facing this issue.

For me works fine.

Thank you @vonbartas.
Can you confirm that eTag: '*' should work? Which API version do you use?

Thank you @vonbartas. Can you confirm that eTag: '*' should work? Which API version do you use?
Maybe you can find other reason why I'm getting message 'Could not find member 'eTag' on object of type 'TemplateResource'.
resource costAnomalyView 'Microsoft.CostManagement/views@2022-10-05-preview' = { name: vName eTag: '*' properties: { accumulated: 'string' chart: 'Table' displayName: 'CostAnomaly' metric: 'ActualCost' query: { dataSet: { aggregation: { totalCost: { function: 'Sum' name: 'PreTaxCost' } } granularity: 'Daily' grouping: [ { name: 'SubscriptionId' type: 'Dimension' } ] sorting: [ { direction: 'Descending' name: 'Subscription' } ] } includeMonetaryCommitment: null timeframe: 'WeekToDate' type: 'Usage' } scope: 'subscriptions/{subscriptionId}' } }

@2022-10-01

unfortunatelly this API version also returns error "The request content was invalid and could not be deserialized: 'Could not find member 'eTag' on object of type 'TemplateResource' :(

@.*** @.***>  - AXP team was added on this thread instead of your team.
Sent from Outlookhttp://aka.ms/weboutlook

From: przlwo @.>
Sent: Friday, October 27, 2023 4:04 AM
To: Azure/bicep-types-az @.>
Cc: BAFS Crew @.>; Mention @.>
Subject: Re: [Azure/bicep-types-az] @.*** not idempotent (Issue #1441)
unfortunatelly this API version also returns error "The request content was invalid and could not be deserialized: 'Could not find member 'eTag' on object of type 'TemplateResource' :(
—
Reply to this email directly, view it on GitHubhttps://github.com/Azure/bicep-types-az/issues/1441#issuecomment-1782721516, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUYECDFMSIIY5DBJYWOK6FDYBOIKJAVCNFSM6AAAAAAWD2R6TOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBSG4ZDCNJRGY.
You are receiving this because you were mentioned.Message ID: @.***>
--000_DS7PR21MB366961B1AE3ACCC8002BDFF2DAA1ADS7PR21MB3669namp
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

FYI  - AXP team was added o=
n this thread instead of your team.

Sent from
Outlook

From: przlwo <notificati=
<EMAIL_ADDRESS>Sent: Friday, October 27, 2023 4:04 AM
To: Azure/bicep-types-az<EMAIL_ADDRESS>Cc: BAFS Crew<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>reply.github.com>
Subject: Re: [Azure/bicep-types-az] Microsoft.CostManagement/exports=
@2021-10-01 not idempotent (Issue #1441)

unfortunatelly this API version also returns error "Th=
e request content was invalid and could not be deserialized: 'Could not fin=
d member 'eTag' on object of type 'TemplateResource' :(
=97
Reply to this email directly,
view it on GitHub, or
unsubscribe.
You are receiving this because you were mentioned.Message
 ID<EMAIL_ADDRESS>

--000_DS7PR21MB366961B1AE3ACCC8002BDFF2DAA1ADS7PR21MB3669namp--
--009_DS7PR21MB366961B1AE3ACCC8002BDFF2DAA1ADS7PR21MB3669namp
Content-Type: message/rfc822
Content-Disposition: attachment;
creation-date="Mon, 30 Oct 2023 18:31:59 GMT";
modification-date="Mon, 30 Oct 2023 18:32:50 GMT"
Received: from DS7PR21MB3054.namprd21.prod.outlook.com (2603:10b6:8:72::17) by
DS7PR21MB3669.namprd21.prod.outlook.com with HTTPS; Fri, 27 Oct 2023 11:04:09
+0000
Received: from DM6PR00CA0048.namprd00.prod.outlook.com (2603:10b6:5:331::17)
by DS7PR21MB3054.namprd21.prod.outlook.com (2603:10b6:8:72::17) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6933.11; Fri, 27 Oct
2023 11:04:05 +0000
Received: from SA2PEPF0000224F.namprd00.prod.outlook.com
(2603:10b6:5:331:cafe::63) by DM6PR00CA0048.outlook.office365.com
(2603:10b6:5:331::17) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6972.0 via Frontend
Transport; Fri, 27 Oct 2023 11:04:05 +0000
Authentication-Results: spf=pass (sender IP is <IP_ADDRESS>)
smtp.mailfrom=github.com; dkim=pass (signature was verified)
header.d=github.com;dmarc=pass action=none
header.from=github.com;compauth=pass reason=100
Received-SPF: Pass (protection.outlook.com: domain of github.com designates
<IP_ADDRESS> as permitted sender) receiver=protection.outlook.com;
client-ip=<IP_ADDRESS>; helo=out-28.smtp.github.com; pr=C
Received: from out-28.smtp.github.com (<IP_ADDRESS>) by
SA2PEPF0000224F.mail.protection.outlook.com (<IP_ADDRESS>) with Microsoft
SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.6982.0 via Frontend Transport; Fri, 27 Oct 2023 11:04:05 +0000
Received: from github.com (hubbernetes-node-4258e3c.ash1-iad.github.net [<IP_ADDRESS>])
by smtp.github.com (Postfix) with ESMTPA id AACCF1003C0
for @.>; Fri, 27 Oct 2023 04:04:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com;
s=pf2023; t=1698404644;
bh=ILcoewVsmmjsEUWTPMV7nCo7ulhse52kqVy5cHu/Ekk=;
h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID:
List-Archive:List-Post:List-Unsubscribe:From;
b=DC9PkLBslSHP6xzhj3oivvxoMrc76PBQVPKe4Q77/L0kWPohtmvRVjy8uIq+ABsRD
ET2gZYJERcSl9BPGYxo7s21wE9RGoN/Qf6uYR6cEhspz8r9RIinHlgRSsNSIiBJ/3c
zHsbEREB0vCa0PF+QANYHIZ1wgz4qFz6qUlycmL8=
Date: Fri, 27 Oct 2023 04:04:04 -0700
From: przlwo @.>
Reply-To: Azure/bicep-types-az @.>
To: Azure/bicep-types-az @.>
Cc: ccmaxpcrew @.>,
Mention @.>
Message-ID: @.>
In-Reply-To: @.>
References: @.>
Subject: Re: [Azure/bicep-types-az]
@. not idempotent (Issue #1441)
Content-Type: multipart/alternative;
boundary="--==mimepart_653b9924a7ec6_75d8045496";
charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: przlwo
X-GitHub-Recipient: ccmaxpcrew
X-GitHub-Reason: mention
List-ID: Azure/bicep-types-az <bicep-types-az.Azure.github.com>
List-Archive: https://github.com/Azure/bicep-types-az
List-Post: @.>
List-Unsubscribe: @.>,
https://github.com/notifications/unsubscribe/AUYECDEN2NV4ITWDVLXJPQLYBOIKJANCNFSM6AAAAAAWD2R6TM
X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply
destinations: @.***
X-GitHub-Recipient-Address: @.***
Return-Path: @.***
X-MS-Exchange-Organization-ExpirationStartTime: 27 Oct 2023 11:04:05.1800
(UTC)
X-MS-Exchange-Organization-ExpirationStartTimeReason: OriginalSubmit
X-MS-Exchange-Organization-ExpirationInterval: 1:00:00:00.0000000
X-MS-Exchange-Organization-ExpirationIntervalReason: OriginalSubmit
X-MS-Exchange-Organization-Network-Message-Id:
e8289d1a-ea02-4acb-38ae-08dbd6dc6f51
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 72f988bf-86f1-41af-91ab-2d7cd011db47:0
X-MS-Exchange-Organization-MessageDirectionality: Incoming
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic:
SA2PEPF0000224F:EE|DS7PR21MB3054:EE_|DS7PR21MB3669:EE_
X-MS-Exchange-Organization-AuthSource:
SA2PEPF0000224F.namprd00.prod.outlook.com
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Office365-Filtering-Correlation-Id: e8289d1a-ea02-4acb-38ae-08dbd6dc6f51
X-MS-Exchange-AtpMessageProperties: SA|SL
X-NO-EXTERNAL-TAGGING: true
X-O365-Sonar-Daas-Pilot: True
X-MS-Exchange-Organization-SCL: 1
X-Microsoft-Antispam: BCL:0;
X-Forefront-Antispam-Report:
CIP:<IP_ADDRESS>;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:out-28.smtp.github.com;PTR:out-28.smtp.github.com;CAT:NONE;SFS:(13230031)(4636009)(451199024)(55016003)(426003)(336012)(66899024)(6286002)(26005)(6266002)(83380400001)(82960400001)(356005)(7596003)(166002)(82950400001)(36756003)(76236004)(7636003)(54906003)(19810500001)(8676002)(4326008)(1096003)(75640400001)(6862004)(450100002)(6966003)(7416002)(34756004)(5660300002)(4006050)(19627405001)(7696005)(33964004)(2616005)(966005)(107886003)(1406899027)(43062005)(43580500001);DIR:INB;
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2023 11:04:05.0706
(UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e8289d1a-ea02-4acb-38ae-08dbd6dc6f51
X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-AuthSource:
SA2PEPF0000224F.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR21MB3054
X-MS-Exchange-Transport-EndToEndLatency: 00:00:04.2132241
X-MS-Exchange-Processed-By-BccFoldering: 15.20.6954.011
X-Microsoft-Antispam-Mailbox-Delivery:
ucf:0;jmr:0;auth:0;dest:I;ENG:(910001)(944506478)(944626604)(920097)(930097)(140003)(1420103);
X-Microsoft-Antispam-Message-Info:
=?Windows-1252?Q?4Gxd4ntC/kTUecXuR4XD31BFQ9NrrfIdOPxYbD3A/4g+FZ01ymTUhmcR?=
=?Windows-1252?Q?7cw9ZhqWF6TY2vQW5G5R6NonObMOnbaQWZzhiwZVQc1MJrYOQgXLtkCD?=
=?Windows-1252?Q?Hx6Q+IHn9vdldLmnc8vhsq9/VKTU67fGTiY9ZZYVWmzAZ6p4uGX11wKM?=
=?Windows-1252?Q?tmqR2N82Zuq8F8NAFzjGJuksPpGI7/U+QK44HcoFdd4X5MYWxWO37sLz?=
=?Windows-1252?Q?Xyhaq48gRbG8BMjhANQ3nVAEKXTr+iN8uwl7Oean9VQp+5Anxv3xWv+P?=
=?Windows-1252?Q?yYqud7Vs01RWIpknzi7bLY5F9khRNFPkdUVBzFSx2tn2jbumDkm02pY+?=
=?Windows-1252?Q?awCAhA4AD35XPo1GucAIn2VU+62HLU0pMxpi+36QDGUStHSxOWoYKCkh?=
=?Windows-1252?Q?LmhnDz7Jzmdt+RUtfvf4uuHifv8H65ublD/uvJATxmYiRYmBuXnhI5ta?=
=?Windows-1252?Q?PRe1iOSI34pdZ3K1dE7e9gdCrN8BcT5c7IvB9cRB11uZ0Wifo7vUCTyS?=
=?Windows-1252?Q?LK24EJRzen7t7WndM06jpQMk1PQnloWlBG7BnPK39W6FohEn+nVLENxO?=
=?Windows-1252?Q?WH5iEmdv5ulOcbvVJAH5mdIH+gtzNgw+5hCiahvjHZmclndSh5KQnhCN?=
=?Windows-1252?Q?ypy9ubKV/zQcikJNv19LlgZlvZLznf9ntH/IW/5UCkIJpjYIUpcEXj2Y?=
=?Windows-1252?Q?NjZnhbpvXvEGGW8h3XJYSWy2XX6qtGhrMPtXLZEPOp4QYShmFpc/0hZ0?=
=?Windows-1252?Q?roaB/tpbmoVGgXPYXsi6PasEEN657hqABKLtsxpLK66wxiYfOQYV/JZy?=
=?Windows-1252?Q?dn1V54p2wfbHLS96QSugEgnCUJuGtDsOeD/DE3kPaMUt+uU+B8TyJJL/?=
=?Windows-1252?Q?W96bdCCxGQvxWR6Hs5worqM4oP/K2bo3qfS10mOyQdmPGM/UvSQ2lusk?=
=?Windows-1252?Q?5uSkf9sBVVl5bPZ5W+E1dyMIANCCJm1uBWTS+0MC/niARUmYirNTATAH?=
=?Windows-1252?Q?6w+/1Rp3/yCyeH0ZO9yUX2ubm9+EXYzDG7arjFZxlBmRIAvS4WMburDY?=
=?Windows-1252?Q?XVbdrKSuU/nRVdagSJDZ12p3QfRHPyzgml1GhK/F6EM3qJVaAt6MsJky?=
=?Windows-1252?Q?DEkotMU1p+QOl8CASICWrP81W4tfN5PCJGGZUFnDEQqJzX8UrmFZ7TEq?=
=?Windows-1252?Q?+himnYZaxard2UQOq+K0zXbkew+7K1JP+7c6cN3rzbUctYpiBcW2ozeL?=
=?Windows-1252?Q?3q47KjXSFp3xdvAJgIyeNYvEmkqgkomzUVnwgxOeCdkVTPkZtf3qnbVo?=
=?Windows-1252?Q?cujx0vW97RdW/ylQGXMBN/STxpKYQBJw52M/5VTJ6GLsrsTBNyIfdfDO?=
=?Windows-1252?Q?oB/0qrAS1nxJQ3LYHwqUXYnx49RRhW9+2QA98suGZTXQIn8J1hM3eMiL?=
=?Windows-1252?Q?rJ8H2pvIQ9hR2hQXcIQtojejPCDuAEX/Y2BW0LDQoGM=3D?=
MIME-Version: 1.0
----==_mimepart_653b9924a7ec6_75d8045496
Content-Type: text/plain;
charset=UTF-8
Content-Transfer-Encoding: 7bit
unfortunatelly this API version also returns error "The request content was invalid and could not be deserialized: 'Could not find member 'eTag' on object of type 'TemplateResource' :(
--
Reply to this email directly or view it on GitHub:
https://github.com/Azure/bicep-types-az/issues/1441#issuecomment-1782721516
You are receiving this because you were mentioned.
Message ID: @.***>
----==_mimepart_653b9924a7ec6_75d8045496
Content-Type: text/html;
charset=UTF-8
Content-Transfer-Encoding: 7bit

unfortunatelly this API version also returns error "The request content was invalid and could not be deserialized: 'Could not find member 'eTag' on object of type 'TemplateResource' :(
â€”Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>
----==_mimepart_653b9924a7ec6_75d8045496--
--009_DS7PR21MB366961B1AE3ACCC8002BDFF2DAA1ADS7PR21MB3669namp
Content-Type: message/rfc822
Content-Disposition: attachment;
creation-date="Mon, 30 Oct 2023 18:31:59 GMT";
modification-date="Mon, 30 Oct 2023 18:32:50 GMT"
Received: from BL1PR21MB3088.namprd21.prod.outlook.com (2603:10b6:208:390::20)
by DS7PR21MB3669.namprd21.prod.outlook.com with HTTPS; Fri, 27 Oct 2023
06:55:27 +0000
Received: from DM6PR00CA0057.namprd00.prod.outlook.com (2603:10b6:5:331::26)
by BL1PR21MB3088.namprd21.prod.outlook.com (2603:10b6:208:390::20) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6954.11; Fri, 27 Oct
2023 06:55:22 +0000
Received: from DM3NAM06FT011.Eop-nam06.prod.protection.outlook.com
(2603:10b6:5:331:cafe::87) by DM6PR00CA0057.outlook.office365.com
(2603:10b6:5:331::26) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6973.0 via Frontend
Transport; Fri, 27 Oct 2023 06:55:22 +0000
Authentication-Results: spf=pass (sender IP is <IP_ADDRESS>)
smtp.mailfrom=github.com; dkim=pass (signature was verified)
header.d=github.com;dmarc=pass action=none
header.from=github.com;compauth=pass reason=100
Received-SPF: Pass (protection.outlook.com: domain of github.com designates
<IP_ADDRESS> as permitted sender) receiver=protection.outlook.com;
client-ip=<IP_ADDRESS>; helo=out-26.smtp.github.com; pr=C
Received: from out-26.smtp.github.com (<IP_ADDRESS>) by
DM3NAM06FT011.mail.protection.outlook.com (<IP_ADDRESS>) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.6954.11 via Frontend Transport; Fri, 27 Oct 2023 06:55:22 +0000
Received: from github.com (hubbernetes-node-faef37f.ash1-iad.github.net [<IP_ADDRESS>])
by smtp.github.com (Postfix) with ESMTPA id D654E600049
for @.>; Thu, 26 Oct 2023 23:55:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com;
s=pf2023; t=1698389721;
bh=PNuDK3FJkcqT/pSnh9hzJaKcMHHn+KsPbeNb/l2oX2w=;
h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID:
List-Archive:List-Post:List-Unsubscribe:From;
b=B9BN40N4efmW9R8HrIc3FxwPiEizXuHOH74ip7NNoAIaRjp5IfEkKXUHSscgwhg+t
zpuC9NYVPAcLdpmDAfQIdp7oSx2hXZxlmwafu/OAAarhRTnZDGaBkKG48A9QK/WsBM
1SDA96J+wEleAgBs0F4l7BI+OIFKpxsX7YCj9Qkk=
Date: Thu, 26 Oct 2023 23:55:21 -0700
From: vonbartas @.>
Reply-To: Azure/bicep-types-az @.>
To: Azure/bicep-types-az @.>
Cc: ccmaxpcrew @.>,
Mention @.>
Message-ID: @.>
In-Reply-To: @.>
References: @.>
Subject: Re: [Azure/bicep-types-az]
@. not idempotent (Issue #1441)
Content-Type: multipart/alternative;
boundary="--==mimepart_653b5ed9d319c_94d8041232f3";
charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: vonbartas
X-GitHub-Recipient: ccmaxpcrew
X-GitHub-Reason: mention
List-ID: Azure/bicep-types-az <bicep-types-az.Azure.github.com>
List-Archive: https://github.com/Azure/bicep-types-az
List-Post: @.>
List-Unsubscribe: @.>,
https://github.com/notifications/unsubscribe/AUYECDETGT35VBBGKMUW2CLYBNLFTANCNFSM6AAAAAAWD2R6TM
X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply
destinations: @.***
X-GitHub-Recipient-Address: @.***
Return-Path: @.***
X-MS-Exchange-Organization-ExpirationStartTime: 27 Oct 2023 06:55:22.3124
(UTC)
X-MS-Exchange-Organization-ExpirationStartTimeReason: OriginalSubmit
X-MS-Exchange-Organization-ExpirationInterval: 1:00:00:00.0000000
X-MS-Exchange-Organization-ExpirationIntervalReason: OriginalSubmit
X-MS-Exchange-Organization-Network-Message-Id:
626137d3-4bdc-486b-57bc-08dbd6b9b098
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 72f988bf-86f1-41af-91ab-2d7cd011db47:0
X-MS-Exchange-Organization-MessageDirectionality: Incoming
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic:
DM3NAM06FT011:EE|BL1PR21MB3088:EE_|DS7PR21MB3669:EE_
X-MS-Exchange-Organization-AuthSource:
DM3NAM06FT011.Eop-nam06.prod.protection.outlook.com
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Office365-Filtering-Correlation-Id: 626137d3-4bdc-486b-57bc-08dbd6b9b098
X-MS-Exchange-AtpMessageProperties: SA|SL
X-NO-EXTERNAL-TAGGING: true
X-O365-Sonar-Daas-Pilot: True
X-MS-Exchange-Organization-SCL: 1
X-Microsoft-Antispam: BCL:0;
X-Forefront-Antispam-Report:
CIP:<IP_ADDRESS>;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:out-26.smtp.github.com;PTR:out-26.smtp.github.com;CAT:NONE;SFS:(13230031)(4636009)(451199024)(6966003)(55016003)(19810500001)(66899024)(54906003)(166002)(33964004)(356005)(7636003)(82960400001)(7596003)(7696005)(82950400001)(26005)(7416002)(76236004)(966005)(36756003)(6286002)(336012)(426003)(6266002)(83380400001)(107886003)(2616005)(5660300002)(4006050)(34756004)(450100002)(4326008)(1096003)(75640400001)(19627405001)(6862004)(8676002)(1406899027)(43062005)(43580500001);DIR:INB;
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2023 06:55:22.2187
(UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 626137d3-4bdc-486b-57bc-08dbd6b9b098
X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-AuthSource:
DM3NAM06FT011.Eop-nam06.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR21MB3088
X-MS-Exchange-Transport-EndToEndLatency: 00:00:05.5023283
X-MS-Exchange-Processed-By-BccFoldering: 15.20.6954.011
X-Microsoft-Antispam-Mailbox-Delivery:
ucf:0;jmr:0;auth:0;dest:I;ENG:(910001)(944506478)(944626604)(920097)(930097)(140003)(1420103);
X-Microsoft-Antispam-Message-Info:
=?Windows-1252?Q?ydBdqp8gsioowKhVZ7MymLHggOwOm80PjRt0ox1jK+NjKMJvA0ryTw2G?=
=?Windows-1252?Q?nTP5pVOoZB0c65I2LrVHjvBLpOlQJ4s6UWK8Mn43gqKWVUP6UllcspOD?=
=?Windows-1252?Q?zBbtLXmJ30IrHl84Tq87ciNTzqyGl76KJLpKI07zThFfUymJyvuwXeKH?=
=?Windows-1252?Q?dHtsa1Xp72vvPlSQHMCmm+K/6pUAgN722iLoyAwZquW3e2vTfm4mg/my?=
=?Windows-1252?Q?vFMyVur37ykKHm9aQzlQeeEKthHKciaVDqI1n49+c/QJ0Jcv14D4cO7R?=
=?Windows-1252?Q?MG5ouPWFWKQKEhea3GyePrCDWA756AXtNU9PHbxDRivsrWORy/A6AjXa?=
=?Windows-1252?Q?iukvOr0K20WD4OUqMAEMBvLjCVUs7xCYlHOUXxP8fHZ0+XTWWF742LYA?=
=?Windows-1252?Q?ckO4gnoqe3kxpUd3ptJSQY/2OqV/0LzCwlkV6aFMjFXtM1TQoJScQEPp?=
=?Windows-1252?Q?rnVHA2ID4Z+Uqgkehz95B0ZteaghNZ+0c4Rsj+2aKphvSYjvLyxalurG?=
=?Windows-1252?Q?lhOaoDODqPexZQaOLKep/HoRa7tm+s7H3XSRvV/ooJX0/eufms3NHpxX?=
=?Windows-1252?Q?7LDxmBTPI8gsZJCNo3cx64DDoKPuQpVozfbxA25H8jJEx7Nw0a8aB5wy?=
=?Windows-1252?Q?joxA8YdbM2YWDTXQi4UouYa8SiUyKX2yiUvzCV3ld0WPaAK/8cOxgO1L?=
=?Windows-1252?Q?ztY2YVtnBDmGp6elqVFpmwcd1v+fIl0CXCBSNjB/JpUvScBLIpGZL8KW?=
=?Windows-1252?Q?JgdwaYrEf9ep3YRHqHsrlrdqXUbNeMzdeHxY/JDzBqv4TKTqNNd/ar02?=
=?Windows-1252?Q?KH9i7ycpJHKScSl8OeodIV6W8J78Ndw7AGUCbveV8DLm78Jm00uSK8la?=
=?Windows-1252?Q?vsRn4XahWBAWnIURa9nMLBw0fMOTPHu71Gd7reLD1NLlwHT2TjnVREEo?=
=?Windows-1252?Q?YG1L6HdnTWaP/LLG6CfbSpk25nac1T4pYExid5yehgp2Miik1uXEG0O2?=
=?Windows-1252?Q?u2Lj5vavi0zQmkHGVGkt06k3tgZYO8LTBhleseXWuLC9MXG8Sss9ejte?=
=?Windows-1252?Q?siF6Nf09Yq/sc/4gN13Fv/ZM0thf9iX0ND92Be1Y5xlAPHh0mWmu//QC?=
=?Windows-1252?Q?CChafhvUiiZTRYZnBr8V+/LNfEJ7OnE7tVGPerMyR9rxz3OANE6CN650?=
=?Windows-1252?Q?BbMUWhQWnxLtGq38NjlaO2wYrcuJksTEX4+6or4T8v1GuUFvMdGiAqh8?=
=?Windows-1252?Q?dx+GeUG0QhaUa7xCgW/3CwOqPdcaAYRGjgMKX0WPlDtzCv9teJ4bHBz4?=
=?Windows-1252?Q?/VK9oYisBT2DLHwuoyiye5TVlXAnqYZyf3EsS5YeIBibcTw5MAxcDuX8?=
=?Windows-1252?Q?D64pCRVVEa1oNIG41EyVcWAEcsLUYf0CP5qVg3Lcj4U9cch1/GW21T+z?=
=?Windows-1252?Q?8ak3JJobOvjCYoduSXxsYGg+qIcF5uY7Fm9l1ey4dlV36EC91j1XrjbD?=
=?Windows-1252?Q?/e8o6evzxsRcQO9df8AdOEIyO//UCaJGRF6uujdiH0sf3I2GOQQvfMK1?=
=?Windows-1252?Q?QoorAbKlBTbvukrVGwT1ZcNPYWA+56MAsdh1CCYQ6VYU9k7Uyi1hpjo3?=
=?Windows-1252?Q?p1o=3D?=
MIME-Version: 1.0
----==_mimepart_653b5ed9d319c_94d8041232f3
Content-Type: text/plain;
charset=UTF-8
Content-Transfer-Encoding: 7bit

Thank you @vonbartas. Can you confirm that eTag: '*' should work? Which API version do you use?
Maybe you can find other reason why I'm getting message 'Could not find member 'eTag' on object of type 'TemplateResource'.
resource costAnomalyView @.**' = { name: vName eTag: '' properties: { accumulated: 'string' chart: 'Table' displayName: 'CostAnomaly' metric: 'ActualCost' query: { dataSet: { aggregation: { totalCost: { function: 'Sum' name: 'PreTaxCost' } } granularity: 'Daily' grouping: [ { name: 'SubscriptionId' type: 'Dimension' } ] sorting: [ { direction: 'Descending' name: 'Subscription' } ] } includeMonetaryCommitment: null timeframe: 'WeekToDate' type: 'Usage' } scope: 'subscriptions/{subscriptionId}' } }

@2022-10-01
--
Reply to this email directly or view it on GitHub:
https://github.com/Azure/bicep-types-az/issues/1441#issuecomment-1782395518
You are receiving this because you were mentioned.
Message ID: @.***>
----==_mimepart_653b5ed9d319c_94d8041232f3
Content-Type: text/html;
charset=UTF-8
Content-Transfer-Encoding: 7bit

Thank you . Can you confirm that eTag: '*' should work? Which API version do you use?
Maybe you can find other reason why I'm getting message 'Could not find member 'eTag' on object of type 'TemplateResource'.
resource costAnomalyView<EMAIL_ADDRESS>= { name: vName eTag: '*' properties: { accumulated: 'string' chart: 'Table' displayName: 'CostAnomaly' metric: 'ActualCost' query: { dataSet: { aggregation: { totalCost: { function: 'Sum' name: 'PreTaxCost' } } granularity: 'Daily' grouping: [ { name: 'SubscriptionId' type: 'Dimension' } ] sorting: [ { direction: 'Descending' name: 'Subscription' } ] } includeMonetaryCommitment: null timeframe: 'WeekToDate' type: 'Usage' } scope: 'subscriptions/{subscriptionId}' } }

â€”Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>
----==_mimepart_653b5ed9d319c_94d8041232f3--
--009_DS7PR21MB366961B1AE3ACCC8002BDFF2DAA1ADS7PR21MB3669namp
Content-Type: message/rfc822
Content-Disposition: attachment;
creation-date="Mon, 30 Oct 2023 18:31:59 GMT";
modification-date="Mon, 30 Oct 2023 18:32:50 GMT"
Received: from IA1PR21MB3473.namprd21.prod.outlook.com (2603:10b6:208:3e2::17)
by DS7PR21MB3669.namprd21.prod.outlook.com with HTTPS; Thu, 26 Oct 2023
13:26:53 +0000
Received: from MN2PR00CA0004.namprd00.prod.outlook.com (2603:10b6:208:224::17)
by IA1PR21MB3473.namprd21.prod.outlook.com (2603:10b6:208:3e2::17) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6954.5; Thu, 26 Oct
2023 13:26:46 +0000
Received: from BL2NAM06FT016.Eop-nam06.prod.protection.outlook.com
(2603:10b6:208:224:cafe::36) by MN2PR00CA0004.outlook.office365.com
(2603:10b6:208:224::17) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6951.0 via Frontend
Transport; Thu, 26 Oct 2023 13:26:46 +0000
Authentication-Results: spf=pass (sender IP is <IP_ADDRESS>)
smtp.mailfrom=github.com; dkim=pass (signature was verified)
header.d=github.com;dmarc=pass action=none
header.from=github.com;compauth=pass reason=100
Received-SPF: Pass (protection.outlook.com: domain of github.com designates
<IP_ADDRESS> as permitted sender) receiver=protection.outlook.com;
client-ip=<IP_ADDRESS>; helo=out-28.smtp.github.com; pr=C
Received: from out-28.smtp.github.com (<IP_ADDRESS>) by
BL2NAM06FT016.mail.protection.outlook.com (<IP_ADDRESS>) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.6954.9 via Frontend Transport; Thu, 26 Oct 2023 13:26:45 +0000
Received: from github.com (hubbernetes-node-8312bd3.ash1-iad.github.net [<IP_ADDRESS>])
by smtp.github.com (Postfix) with ESMTPA id 7FF9C101172
for @.>; Thu, 26 Oct 2023 06:26:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com;
s=pf2023; t=1698326805;
bh=uV4Te1MqfKpy7BUWQ2gcaAgQsVEj8SLvB53we2ynPmA=;
h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID:
List-Archive:List-Post:List-Unsubscribe:From;
b=QIA0gPE+RTvA46ebg4CNsNrJSPEbwqud02wsZTuqepzhZvq9z9YOCCoSQD71CBcI4
ujCJbbCER12BK4gbUKG9qP+guOWakElilFCHKgJTuk5wXe4fTjEKJQJDGb2Rb8OgND
836TP1Uf59XXqFCkw21hoHg+fLpDoE4k++wgl3sQ=
Date: Thu, 26 Oct 2023 06:26:45 -0700
From: przlwo @.>
Reply-To: Azure/bicep-types-az @.>
To: Azure/bicep-types-az @.>
Cc: ccmaxpcrew @.>,
Mention @.>
Message-ID: @.>
In-Reply-To: @.>
References: @.>
Subject: Re: [Azure/bicep-types-az]
@. not idempotent (Issue #1441)
Content-Type: multipart/alternative;
boundary="--==mimepart_653a69157d746_87d8041304ab";
charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: przlwo
X-GitHub-Recipient: ccmaxpcrew
X-GitHub-Reason: mention
List-ID: Azure/bicep-types-az <bicep-types-az.Azure.github.com>
List-Archive: https://github.com/Azure/bicep-types-az
List-Post: @.>
List-Unsubscribe: @.>,
https://github.com/notifications/unsubscribe/AUYECDAN3QDXALGQQOZGQJDYBJQJLANCNFSM6AAAAAAWD2R6TM
X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply
destinations: @.***
X-GitHub-Recipient-Address: @.***
Return-Path: @.***
X-MS-Exchange-Organization-ExpirationStartTime: 26 Oct 2023 13:26:45.6446
(UTC)
X-MS-Exchange-Organization-ExpirationStartTimeReason: OriginalSubmit
X-MS-Exchange-Organization-ExpirationInterval: 1:00:00:00.0000000
X-MS-Exchange-Organization-ExpirationIntervalReason: OriginalSubmit
X-MS-Exchange-Organization-Network-Message-Id:
d9f4b841-537e-48e5-b7a0-08dbd6273356
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 72f988bf-86f1-41af-91ab-2d7cd011db47:0
X-MS-Exchange-Organization-MessageDirectionality: Incoming
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic:
BL2NAM06FT016:EE|IA1PR21MB3473:EE_|DS7PR21MB3669:EE_
X-MS-Exchange-Organization-AuthSource:
BL2NAM06FT016.Eop-nam06.prod.protection.outlook.com
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Office365-Filtering-Correlation-Id: d9f4b841-537e-48e5-b7a0-08dbd6273356
X-MS-Exchange-AtpMessageProperties: SA|SL
X-NO-EXTERNAL-TAGGING: true
X-O365-Sonar-Daas-Pilot: True
X-MS-Exchange-Organization-SCL: 1
X-Microsoft-Antispam: BCL:0;
X-Forefront-Antispam-Report:
CIP:<IP_ADDRESS>;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:out-28.smtp.github.com;PTR:out-28.smtp.github.com;CAT:NONE;SFS:(13230031)(4636009)(451199024)(54906003)(19810500001)(66899024)(966005)(1096003)(4006050)(82960400001)(4326008)(82950400001)(7416002)(6862004)(5660300002)(36756003)(76236004)(6966003)(7596003)(7636003)(356005)(450100002)(34756004)(8676002)(166002)(75640400001)(33964004)(7696005)(336012)(6286002)(6266002)(2616005)(426003)(26005)(19627405001)(83380400001)(107886003)(55016003)(1406899027)(43062005)(43580500001);DIR:INB;
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2023 13:26:45.5978
(UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d9f4b841-537e-48e5-b7a0-08dbd6273356
X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-AuthSource:
BL2NAM06FT016.Eop-nam06.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR21MB3473
X-MS-Exchange-Transport-EndToEndLatency: 00:00:07.8918885
X-MS-Exchange-Processed-By-BccFoldering: 15.20.6954.005
X-Microsoft-Antispam-Mailbox-Delivery:
ucf:0;jmr:0;auth:0;dest:I;ENG:(910001)(944506478)(944626604)(920097)(930097)(140003)(1420103);
X-Microsoft-Antispam-Message-Info:
=?Windows-1252?Q?gRmiYI7HNERQ1fi9D0qyW+VCwzO9lLwpq8rWZRjH55iupucG6XIapp88?=
=?Windows-1252?Q?RErXqfOZEQrkKge8BVfqs7fH5EEpwa356XwRKPnYlLbZ+7wQr2H/e+JV?=
=?Windows-1252?Q?7N4UK87OZ/iX/FB1IJej08Dwo/aeDbxn8uhmHitaUTH5NweYodXKOoGO?=
=?Windows-1252?Q?XDou8ygmeqtSr64oRQxavufWxfQk1V//avTPwcqVz1xvbyhAX6dj42bH?=
=?Windows-1252?Q?wJLFYdvEHOvFwtqzNvvr3a4YkKoBicnPSqv3TFAjPaxLstyf3XakdlR2?=
=?Windows-1252?Q?6UdW27rV8YjsqhEjwiPLxq0Bn2wowjaJV0kF9Vq8OvSIOuk8Y9UNNWYS?=
=?Windows-1252?Q?ykm8Syp2lRpiTTAb0HMAwEbCO9UBt4kvQhlQ13UTvYIhMFYWpZnEVhTD?=
=?Windows-1252?Q?67thUGc/TuTIcbUrvE5PZe90P1sM5D71GflXETfKosSYZ+wWr/00uJXZ?=
=?Windows-1252?Q?KsHWEvco7RnvT+p16s9Bih62yx2vvn5KUbjqLBc2L0/61juqiKSj8Qco?=
=?Windows-1252?Q?ANriXCmpPYgQazTaS0rPsxXspB8iOqHb9cg2XoBjUyi4Sg3QtxjVXNFU?=
=?Windows-1252?Q?X9YrMN2LWZGfakTym7LoDyQ8mAHfk8ovfUtqXjy2LZv87qnvie+MpVuF?=
=?Windows-1252?Q?SfD28q9LC9T6HShEwHY2owri84kRN4rrhfowZsh3yhr5qxdX9LcHOt/p?=
=?Windows-1252?Q?FnEUNd6oJpjSfE9tz9lqE12psfZuTySdQystdjl6yIZGNo3AYBQFgDR8?=
=?Windows-1252?Q?VRNaOtTWB0s2bQjUxdVzPFqTgytAxWhCGY7zDgolWFt7FuYCIw5V+eI5?=
=?Windows-1252?Q?CstlZz5iegYpkSo0r336MkgD5q9PTqYRXhhRTocKG6MljZfgu8nr5dKF?=
=?Windows-1252?Q?TkPsS6SLnzIUrDAAOAQVn0acPw29pD21rHeXuiYzu24tNHUFSo5URjks?=
=?Windows-1252?Q?spaTGY9Iuj3xNp9z+Q29AVdYZqsaq8uK7ujKX96xKy8S/iUnCmd3O4C9?=
=?Windows-1252?Q?GDRyMpn/WtsKW8Arl2FWb6MLCLeN2ceJhadFzaPC2eq+0HtJ+jkiR1XD?=
=?Windows-1252?Q?mnVFrgfo1+2n0MYxzuQfNSRhL0JlcSx/H5G8bqLEwg2pyICzNfPyug2W?=
=?Windows-1252?Q?wkB6/ZijKOpGgAHdUCPd+R/LuNxqFxTg2SHX+5a6687MCx4o7LWX3g9/?=
=?Windows-1252?Q?zwkdrXBOPgbpYUdPUjViQty8aOH9L8/qdXiPUTOSlyXNedsqigPQxBjI?=
=?Windows-1252?Q?JL/36rr+DlcLUdCKzQ1lJgmzOl9MCo9LZMI1jSXnM0bCZ7t+HyML2Yb2?=
=?Windows-1252?Q?RbOtJfjeRaoBqwYaSYBVf4Bkl61F06jqfWRbwCJSKtXIHCOTV4UhyI/u?=
=?Windows-1252?Q?cHLT2+BBW8MAbMwONiY7QnjEYKbu+aCSwk0fkFQXyBwgmy+c0Kx7X7PK?=
=?Windows-1252?Q?VBO/HfrYtR2eqAUda0MPs5jMNirgFpRsYphKtBfsgU4=3D?=
MIME-Version: 1.0
----==_mimepart_653a69157d746_87d8041304ab
Content-Type: text/plain;
charset=UTF-8
Content-Transfer-Encoding: 7bit
Thank you @vonbartas.
Can you confirm that eTag: '*' should work? Which API version do you use?
--
Reply to this email directly or view it on GitHub:
https://github.com/Azure/bicep-types-az/issues/1441#issuecomment-1781124200
You are receiving this because you were mentioned.
Message ID: @.***>
----==_mimepart_653a69157d746_87d8041304ab
Content-Type: text/html;
charset=UTF-8
Content-Transfer-Encoding: 7bit

Thank you .
Can you confirm that eTag: '*' should work? Which API version do you use?
â€”Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>
----==_mimepart_653a69157d746_87d8041304ab--
--009_DS7PR21MB366961B1AE3ACCC8002BDFF2DAA1ADS7PR21MB3669namp
Content-Type: message/rfc822
Content-Disposition: attachment;
creation-date="Mon, 30 Oct 2023 18:32:00 GMT";
modification-date="Mon, 30 Oct 2023 18:32:50 GMT"
Received: from SJ1PR21MB3554.namprd21.prod.outlook.com (2603:10b6:a03:452::17)
by DS7PR21MB3669.namprd21.prod.outlook.com with HTTPS; Thu, 26 Oct 2023
13:18:29 +0000
Received: from DM6PR00CA0031.namprd00.prod.outlook.com (2603:10b6:5:114::44)
by SJ1PR21MB3554.namprd21.prod.outlook.com (2603:10b6:a03:452::17) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6954.8; Thu, 26 Oct
2023 13:18:25 +0000
Received: from DM3NAM06FT008.Eop-nam06.prod.protection.outlook.com
(2603:10b6:5:114:cafe::b6) by DM6PR00CA0031.outlook.office365.com
(2603:10b6:5:114::44) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6973.0 via Frontend
Transport; Thu, 26 Oct 2023 13:18:25 +0000
Authentication-Results: spf=pass (sender IP is <IP_ADDRESS>)
smtp.mailfrom=github.com; dkim=pass (signature was verified)
header.d=github.com;dmarc=pass action=none
header.from=github.com;compauth=pass reason=100
Received-SPF: Pass (protection.outlook.com: domain of github.com designates
<IP_ADDRESS> as permitted sender) receiver=protection.outlook.com;
client-ip=<IP_ADDRESS>; helo=out-17.smtp.github.com; pr=C
Received: from out-17.smtp.github.com (<IP_ADDRESS>) by
DM3NAM06FT008.mail.protection.outlook.com (<IP_ADDRESS>) with Microsoft
SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.6954.9 via Frontend Transport; Thu, 26 Oct 2023 13:18:25 +0000
Received: from github.com (hubbernetes-node-6415157.va3-iad.github.net [<IP_ADDRESS>])
by smtp.github.com (Postfix) with ESMTPA id D0C684118A
for @.>; Thu, 26 Oct 2023 06:18:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com;
s=pf2023; t=1698326304;
bh=LKtFODSc4BnCs/Eblp4wTPDtr54QR/uR5WCp18VksZ0=;
h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID:
List-Archive:List-Post:List-Unsubscribe:From;
b=mHmtMazc3sKxQNwx2my2oa43A0NBf+vWIPT//gNYNoMDpG5qSChiEBBBO32JXy9Aj
Ft93tqPc3R7pbLAvQpHixMaF72hpC5LFALdOnW6zVn7voIdV4JjunRJLb1YT90YRU0
uyCGvjguHSloFos1kt8Z9pfcjnkgbj2OFBTPqIfI=
Date: Thu, 26 Oct 2023 06:18:24 -0700
From: vonbartas @.>
Reply-To: Azure/bicep-types-az @.>
To: Azure/bicep-types-az @.>
Cc: ccmaxpcrew @.>,
Mention @.>
Message-ID: @.>
In-Reply-To: @.>
References: @.>
Subject: Re: [Azure/bicep-types-az]
@. not idempotent (Issue #1441)
Content-Type: multipart/alternative;
boundary="--==mimepart_653a6720c5118_74d8041108ed";
charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: vonbartas
X-GitHub-Recipient: ccmaxpcrew
X-GitHub-Reason: mention
List-ID: Azure/bicep-types-az <bicep-types-az.Azure.github.com>
List-Archive: https://github.com/Azure/bicep-types-az
List-Post: @.>
List-Unsubscribe: @.>,
https://github.com/notifications/unsubscribe/AUYECDBBAD55GG4KQYU7Q3TYBJPKBANCNFSM6AAAAAAWD2R6TM
X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply
destinations: @.***
X-GitHub-Recipient-Address: @.***
Return-Path: @.***
X-MS-Exchange-Organization-ExpirationStartTime: 26 Oct 2023 13:18:25.3263
(UTC)
X-MS-Exchange-Organization-ExpirationStartTimeReason: OriginalSubmit
X-MS-Exchange-Organization-ExpirationInterval: 1:00:00:00.0000000
X-MS-Exchange-Organization-ExpirationIntervalReason: OriginalSubmit
X-MS-Exchange-Organization-Network-Message-Id:
6134672b-a942-4768-30db-08dbd6260920
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 72f988bf-86f1-41af-91ab-2d7cd011db47:0
X-MS-Exchange-Organization-MessageDirectionality: Incoming
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic:
DM3NAM06FT008:EE|SJ1PR21MB3554:EE_|DS7PR21MB3669:EE_
X-MS-Exchange-Organization-AuthSource:
DM3NAM06FT008.Eop-nam06.prod.protection.outlook.com
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Office365-Filtering-Correlation-Id: 6134672b-a942-4768-30db-08dbd6260920
X-MS-Exchange-AtpMessageProperties: SA|SL
X-NO-EXTERNAL-TAGGING: true
X-O365-Sonar-Daas-Pilot: True
X-MS-Exchange-Organization-SCL: 1
X-Microsoft-Antispam: BCL:0;
X-Forefront-Antispam-Report:
CIP:<IP_ADDRESS>;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:out-17.smtp.github.com;PTR:out-17.smtp.github.com;CAT:NONE;SFS:(13230031)(4636009)(451199024)(6966003)(54906003)(19810500001)(7416002)(5660300002)(1096003)(4006050)(4326008)(6862004)(8676002)(966005)(450100002)(34756004)(36756003)(75640400001)(19627405001)(7696005)(33964004)(7636003)(356005)(7596003)(166002)(336012)(426003)(26005)(76236004)(107886003)(6266002)(6286002)(2616005)(82950400001)(82960400001)(55016003)(83380400001)(66899024)(1406899027)(43062005)(43580500001);DIR:INB;
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2023 13:18:25.2325
(UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6134672b-a942-4768-30db-08dbd6260920
X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-AuthSource:
DM3NAM06FT008.Eop-nam06.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR21MB3554
X-MS-Exchange-Transport-EndToEndLatency: 00:00:04.5979673
X-MS-Exchange-Processed-By-BccFoldering: 15.20.6954.005
X-Microsoft-Antispam-Mailbox-Delivery:
ucf:0;jmr:0;auth:0;dest:I;ENG:(910001)(944506478)(944626604)(920097)(930097)(140003)(1420103);
X-Microsoft-Antispam-Message-Info:
=?Windows-1252?Q?PM92tNkHvb5hGV8740SisUMfB8LOmtDf3l2THjB1UswPOBYNjKyG42E5?=
=?Windows-1252?Q?WzVBI9Jke3CRfs13PoulykOLZYg38CraxtlLj2zab/OnNS5IRorEf2hx?=
=?Windows-1252?Q?B57ov5unYUEAnBMbQgycxtek369cHawC6DMDfoo/in+1PhRMO0jUegU0?=
=?Windows-1252?Q?wa/Ihu55nqMgSr2S07tbm0s58sHHSq3lZVq+dnpJiJ/GddFkijDdzOgN?=
=?Windows-1252?Q?JMOlMhAjsBB9bUPQ66eSTWQ+adlq9PYC5zC0cFZgf929bmgxLvm1mo+G?=
=?Windows-1252?Q?wDPckaoS7wxVWHYTw6I2jZGPeXdVwJp2SQTHibpMHystZdFOQtV0mL2C?=
=?Windows-1252?Q?qQA3m+Jl8y3rkuol0h8QwaGTw3goYvi9k76D0WnD7OekpHNCPdVP/QvC?=
=?Windows-1252?Q?HxzDukLIWHR3RWWV5yG1Ts96iBPyUilQaZofrLymLwMof4D4WxwFShZ2?=
=?Windows-1252?Q?KrNo++nUJA6UQY/Hu2nNXdRYyRxeh47m1I/tIZaFha9zLkFtYXz7eyfi?=
=?Windows-1252?Q?6MKMrNnmmOYNTQf1eQLyOBzeJ+pFP/faOdVvNy8LtJoSw2QTqoirHy5F?=
=?Windows-1252?Q?+NYPRewkAVrh7lpsf8veSZJJ/dab1LQTclgh0Enmyh2G8lKLLHYvtvmU?=
=?Windows-1252?Q?+RzvsqNFfJKGRUcRDzXC8QtMc+njsWLvou394nkKGySKK0xvXiSXSwjc?=
=?Windows-1252?Q?RRRP/NPLf281GvmxOsmTyMEu684gyGCEzXM6F0nzRRW/fpHxXbKmwPiA?=
=?Windows-1252?Q?DQGfqW8kaZy6zXO7Hlx0178dAxukYD1rIsBgzarOnL6UKuS6fNVFcRF0?=
=?Windows-1252?Q?/xobPC3abxK1/NOVfAaCfG96/nPWksKEejvPiMWNwXDyb8p1NY0mUl2P?=
=?Windows-1252?Q?8MV2qgvlvW11Y9/f0qtMSDX19lG8LwO4qgfIbft9yKA2Hb3OyTN7oZop?=
=?Windows-1252?Q?yTRhfNAzbs9ojuJlHrSbhbGJJLSvJ2s9CNOosihrZW1VvJwpBxXoQ14T?=
=?Windows-1252?Q?VgTV3sEC/pzPUnrsZB36EJQ7L+bggvSUqd9oD34UV3VmPucWJy6NvtDw?=
=?Windows-1252?Q?pLQiOs3fGTj4JSPjnMKo0YIxKLtNVDJGrtLSRuDI6xaqjtOpzsOU+lyW?=
=?Windows-1252?Q?5sKRWuxBlaDbgnV13CU2W6sknCH/62TYrrXsnCdqMa68xK/eM5sFhW7e?=
=?Windows-1252?Q?xnsw0D2UdGtBttt1IjCu2Y6shuE6IBhM0aCLtv2+HBNekshHvV25WHXr?=
=?Windows-1252?Q?tAPKa2xgC1WgE2std+NpN8xo328hWlI0raWoI0RewL1BPypq8yRy4eQ7?=
=?Windows-1252?Q?h2xCkpHq36rz7S85muGWTtJihAGHIRkovRI8b5ygY444kbwfk2vGhrCJ?=
=?Windows-1252?Q?I8fht+qYLXcKCRjeNsdFC9q6iwzmZx5JqaV9AvxNIVXwbnruuNdCH9s0?=
=?Windows-1252?Q?irYwAWD2nkN4GMM6VFTZSAURpN9aQ/ZemDhOStrIqKM=3D?=
MIME-Version: 1.0
----==_mimepart_653a6720c5118_74d8041108ed
Content-Type: text/plain;
charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi, does the issue with Microsoft.CostManagement/views endpoint was resolved? Currently I'm facing this issue.

For me works fine.
--
Reply to this email directly or view it on GitHub:
https://github.com/Azure/bicep-types-az/issues/1441#issuecomment-1781108327
You are receiving this because you were mentioned.
Message ID: @.***>
----==_mimepart_653a6720c5118_74d8041108ed
Content-Type: text/html;
charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi, does the issue with Microsoft.CostManagement/views endpoint was resolved? Currently I'm facing this issue.

For me works fine.
â€”Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>
----==_mimepart_653a6720c5118_74d8041108ed--
--009_DS7PR21MB366961B1AE3ACCC8002BDFF2DAA1ADS7PR21MB3669namp
Content-Type: message/rfc822
Content-Disposition: attachment;
creation-date="Mon, 30 Oct 2023 18:32:00 GMT";
modification-date="Mon, 30 Oct 2023 18:32:50 GMT"
Received: from DM4PR21MB3106.namprd21.prod.outlook.com (2603:10b6:8:62::18) by
DS7PR21MB3669.namprd21.prod.outlook.com with HTTPS; Thu, 26 Oct 2023 12:45:43
+0000
Received: from DM6PR00CA0022.namprd00.prod.outlook.com (2603:10b6:5:114::35)
by DM4PR21MB3106.namprd21.prod.outlook.com (2603:10b6:8:62::18) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6954.8; Thu, 26 Oct
2023 12:45:40 +0000
Received: from CY4PEPF0000FF2D.namprd00.prod.outlook.com
(2603:10b6:5:114:cafe::8b) by DM6PR00CA0022.outlook.office365.com
(2603:10b6:5:114::35) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6972.0 via Frontend
Transport; Thu, 26 Oct 2023 12:45:40 +0000
Authentication-Results: spf=pass (sender IP is <IP_ADDRESS>)
smtp.mailfrom=github.com; dkim=pass (signature was verified)
header.d=github.com;dmarc=pass action=none
header.from=github.com;compauth=pass reason=100
Received-SPF: Pass (protection.outlook.com: domain of github.com designates
<IP_ADDRESS> as permitted sender) receiver=protection.outlook.com;
client-ip=<IP_ADDRESS>; helo=out-26.smtp.github.com; pr=C
Received: from out-26.smtp.github.com (<IP_ADDRESS>) by
CY4PEPF0000FF2D.mail.protection.outlook.com (<IP_ADDRESS>) with Microsoft
SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.6975.0 via Frontend Transport; Thu, 26 Oct 2023 12:45:40 +0000
Received: from github.com (hubbernetes-node-c0cb37e.ash1-iad.github.net [<IP_ADDRESS>])
by smtp.github.com (Postfix) with ESMTPA id 13627600C2A
for @.>; Thu, 26 Oct 2023 05:45:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com;
s=pf2023; t=1698324340;
bh=2r8POlsW+e2oZDc8T284qGZmiJsLa28Axr20q7jTaZA=;
h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID:
List-Archive:List-Post:List-Unsubscribe:From;
b=D3dk6xOQN3YrqDWqTEM1dQdYylXs71nIXLdV+/vx4TVM/fX5YouT27HvFmYZaske8
3RbyNJyPTukDPVQ3JL/AY0xRnI3OYXzuc6sETxzhbe1li8+CJAtfb7e6yV2i6dihW/
Dj8PkDApjet/L665cAnS9pdbSCvkPRjvnoyzr4O8=
Date: Thu, 26 Oct 2023 05:45:40 -0700
From: przlwo @.>
Reply-To: Azure/bicep-types-az @.>
To: Azure/bicep-types-az @.>
Cc: ccmaxpcrew @.>,
Mention @.>
Message-ID: @.>
In-Reply-To: @.>
References: @.>
Subject: Re: [Azure/bicep-types-az]
@. not idempotent (Issue #1441)
Content-Type: multipart/alternative;
boundary="--==mimepart_653a5f7410bb0_7ad804321115";
charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: przlwo
X-GitHub-Recipient: ccmaxpcrew
X-GitHub-Reason: mention
List-ID: Azure/bicep-types-az <bicep-types-az.Azure.github.com>
List-Archive: https://github.com/Azure/bicep-types-az
List-Post: @.>
List-Unsubscribe: @.>,
https://github.com/notifications/unsubscribe/AUYECDB7Z7XWQY3F5UXBVP3YBJLPJANCNFSM6AAAAAAWD2R6TM
X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply
destinations: @.***
X-GitHub-Recipient-Address: @.***
Return-Path: @.***
X-MS-Exchange-Organization-ExpirationStartTime: 26 Oct 2023 12:45:40.6883
(UTC)
X-MS-Exchange-Organization-ExpirationStartTimeReason: OriginalSubmit
X-MS-Exchange-Organization-ExpirationInterval: 1:00:00:00.0000000
X-MS-Exchange-Organization-ExpirationIntervalReason: OriginalSubmit
X-MS-Exchange-Organization-Network-Message-Id:
5882e8b3-1da9-4005-3be8-08dbd621761c
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 72f988bf-86f1-41af-91ab-2d7cd011db47:0
X-MS-Exchange-Organization-MessageDirectionality: Incoming
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic:
CY4PEPF0000FF2D:EE|DM4PR21MB3106:EE_|DS7PR21MB3669:EE_
X-MS-Exchange-Organization-AuthSource:
CY4PEPF0000FF2D.namprd00.prod.outlook.com
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Office365-Filtering-Correlation-Id: 5882e8b3-1da9-4005-3be8-08dbd621761c
X-MS-Exchange-AtpMessageProperties: SA|SL
X-NO-EXTERNAL-TAGGING: true
X-O365-Sonar-Daas-Pilot: True
X-MS-Exchange-Organization-SCL: 1
X-Microsoft-Antispam: BCL:0;
X-Forefront-Antispam-Report:
CIP:<IP_ADDRESS>;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:out-26.smtp.github.com;PTR:out-26.smtp.github.com;CAT:NONE;SFS:(13230031)(4636009)(451199024)(34756004)(7416002)(19627405001)(19810500001)(6966003)(54906003)(107886003)(8676002)(1096003)(4326008)(75640400001)(450100002)(6862004)(36756003)(5660300002)(4006050)(166002)(76236004)(966005)(83380400001)(55016003)(82960400001)(82950400001)(426003)(336012)(7636003)(7596003)(6266002)(356005)(2616005)(26005)(6286002)(33964004)(7696005)(66899024)(1406899027)(43062005)(43580500001);DIR:INB;
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2023 12:45:40.5634
(UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5882e8b3-1da9-4005-3be8-08dbd621761c
X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-AuthSource:
CY4PEPF0000FF2D.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR21MB3106
X-MS-Exchange-Transport-EndToEndLatency: 00:00:03.4052296
X-MS-Exchange-Processed-By-BccFoldering: 15.20.6954.005
X-Microsoft-Antispam-Mailbox-Delivery:
ucf:0;jmr:0;auth:0;dest:I;ENG:(910001)(944506478)(944626604)(920097)(930097)(140003)(1420103);
X-Microsoft-Antispam-Message-Info:
=?Windows-1252?Q?94zoLOcmNGr1ngiliturLg7e0DoS0GPH574tK0jzKRxhmWQ1x+AlAW0i?=
=?Windows-1252?Q?XXtzbS1DnEKWAk3YoCf76SJEw3jj8qVhXK2h/MFwbmych5emty25aD2z?=
=?Windows-1252?Q?eGXwiL24KyjqPdznwxYR0yLo/TgMADWEFm6ywbIng1r88JcLhVAGAd/C?=
=?Windows-1252?Q?7vNRubhpfXeghdzMhIQeAivKfvsSIYkKgynm+zHyaKrpxE8EiIwK58mU?=
=?Windows-1252?Q?M8ouFGFGJpftrGQM9xE8GAJIolh72sAkne9EudzTZcoj9WNcmAnmzS2C?=
=?Windows-1252?Q?mlZeJhh9sMyvqtOmSCc8AdNEbjFxteB68jmGmNMuipLyKNZ4LMq2729g?=
=?Windows-1252?Q?dCSrV1DL91hQmNCWwtdJ/ZQaeH4T+RTj44n5R2zdQQaWaZcblCDXTSor?=
=?Windows-1252?Q?LxrJV0rz8dPK9GXqN7MFiuvXQxTY/8tZ6DRbp2t30s8GYk5tdCRu55ke?=
=?Windows-1252?Q?S/9oh0W+1xHM444sWU3CIDBecdqNhedRvVPDtmyu6kb/o3WWbGVAsw7s?=
=?Windows-1252?Q?Crk2Ss6DOPQn30gCwPS945QXT8PVOvlHEMYq6cuZOuDOJkO9FbxSp+lT?=
=?Windows-1252?Q?h0aOVLXPHnyII7HPj4SijBylMu5gCrIoZl1Vh4AER1u3BfG54nFFImks?=
=?Windows-1252?Q?aoYGjfxDgOWL0hWDQJICzBt5DrO3AkqpALTmbSYwsCPH1DNAcF3IriFy?=
=?Windows-1252?Q?3bYcaL7UFGAgoTyAbcCkbuTiRd3YnFlTQvjJ7bJNJr+Gvo1hphX4OzXh?=
=?Windows-1252?Q?QPGrWvx316LLUipMk0KAGcRqvlR0XXRQLxIokuDb9MzscRPOIefBSvHe?=
=?Windows-1252?Q?c4rf/dh1OXNcsATR27PdGMOCJq6OgOTiIS/1ERQKeMndgfcR+W5ppqBW?=
=?Windows-1252?Q?+P+HVocYuMfh9kCh7yPYlrtPsI0C3HEUdyD6xo3641ZN5uZ6soiGDWp4?=
=?Windows-1252?Q?ys1NghWnX3vJcmxPGxTSHb90uOCTqoLh/klMXWKGgWpF4EJm8XxZkjXQ?=
=?Windows-1252?Q?CXvpi8KeqR212oMzUNSIuXHscGS0Uv9eVjli1vR2rHIP0+kWdmbtPB0J?=
=?Windows-1252?Q?iMU06yIYBzSKVvRNnhbCz60LfY2c8SvrVD+Q+juDgp/M5zEKi6H8fQ8z?=
=?Windows-1252?Q?Tfvg7jcqawkLimtPa6FQvRaMQ8TBD9V3JoS6W9Q2FIA4u+EY1maOaw9j?=
=?Windows-1252?Q?k4Fn8E3VlJydEBnIfyuBa6E9LOd7DyVXrbGHALPmwYKBT196yvAy+uul?=
=?Windows-1252?Q?hrt7jZjDqktq61SB9kEs4Pd2DvPR3zQap9I9TQSLOQUbEiU5wTde0aS3?=
=?Windows-1252?Q?AtS64bodAmvg2xBzYOekSdYJao75dnNeUPOtUsPXDfpY6jooWV4n3b8o?=
=?Windows-1252?Q?XZW7dhoYCJf+bI6jFdhxMf5YKv+kNnWsfc5MGqTDwPfw0xw3r1ebAkWd?=
=?Windows-1252?Q?6cd6S0YJ4K+VuwocBEVri9TJbNhZwJS2szayGJm2lZM=3D?=
MIME-Version: 1.0
----==_mimepart_653a5f7410bb0_7ad804321115
Content-Type: text/plain;
charset=UTF-8
Content-Transfer-Encoding: 7bit
Hi, does the issue with Microsoft.CostManagement/views endpoint was resolved? Currently I'm facing this issue.
--
Reply to this email directly or view it on GitHub:
https://github.com/Azure/bicep-types-az/issues/1441#issuecomment-1781051812
You are receiving this because you were mentioned.
Message ID: @.***>
----==_mimepart_653a5f7410bb0_7ad804321115
Content-Type: text/html;
charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi, does the issue with Microsoft.CostManagement/views endpoint was resolved? Currently I'm facing this issue.
â€”Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>
----==_mimepart_653a5f7410bb0_7ad804321115--
--009_DS7PR21MB366961B1AE3ACCC8002BDFF2DAA1ADS7PR21MB3669namp
Content-Type: message/rfc822
Content-Disposition: attachment;
creation-date="Mon, 30 Oct 2023 18:32:00 GMT";
modification-date="Mon, 30 Oct 2023 18:32:50 GMT"
Received: from MN0PR21MB3751.namprd21.prod.outlook.com (2603:10b6:208:3ca::10)
by DS7PR21MB3669.namprd21.prod.outlook.com with HTTPS; Mon, 8 May 2023
18:19:33 +0000
Received: from DM6PR00CA0038.namprd00.prod.outlook.com (2603:10b6:5:331::7) by
MN0PR21MB3751.namprd21.prod.outlook.com (2603:10b6:208:3ca::10) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6411.2; Mon, 8 May
2023 18:19:30 +0000
Received: from CB1PEPF00003D79.namprd00.prod.outlook.com
(2603:10b6:5:331:cafe::53) by DM6PR00CA0038.outlook.office365.com
(2603:10b6:5:331::7) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6405.0 via Frontend
Transport; Mon, 8 May 2023 18:19:30 +0000
Authentication-Results: spf=pass (sender IP is <IP_ADDRESS>)
smtp.mailfrom=github.com; dkim=pass (signature was verified)
he

Is there an update to this issue?
I can confirm, using...
resource costManagementView 'Microsoft.CostManagement/views@2023-11-01' ...
Still returns:
Status Message: Etag value required for update operation of view: test cost view. Please get the latest to avoid overwrite. (Request ID: <OBSCURED>) (Code:400)
I've written some modules to create action groups, create budgets (action group assigned), create the cost management views (with the same filter as the budget and the budget assigned as a KPI), and then a scheduled report of the view.  I've got ~15-20 of these setup so it was ripe for building it in bicep.
My challenge with this bug -
Since the Microsoft.CostManagement/views is not idempotent, I have to break the deployment into 3 components -

Build action group and budget
Build the cost management view (run only once)
build the schedule on top of the view

If I have to tweak the view, I have to delete the cost management view and then re-run #2 and #3 above.  Since the view is deleted/re-created, users get an email anytime I have to do this causing confusion to the audience receiving the budget alerts (ex - "why am I getting so many messages that I've subscribed to the weekly report?!")
Side note - does anyone have a way to 'mass delete' cost management views?  I was unable to find an azure powershell or cli command to do this so am manually purging them if needed.
Thanks!

@pfoppe I have the same issue, but in Terraform. @alex-frankel any update on this, when the API will be fixed?


Refactor/add dependency injection

@skraynick and here's the pull request. good luck! ;) btw, the last is the merge commit because I first wanted to merge your sugar commits and maybe fix any problems, but merging went more or less smoothly, just some minor fixes.
one note: this branch breaks travis building again, it's complaining mostly about volley now. That will be fixed in another branch when I refactor volley out, but I wanted first to push this one out.
also, the bootstrapper is now integrated and not a separate library as before.

@mrsasha awesome(ly) big. It will focus my attention on something other than sad stuff. I will read through over the next couple of days.  I don't have reliable internet at the moment, sorting it out.. so working on stuff from coffee shops mainly.  ;)

ah, the disconnected life! no hurry, everything's under control.

@mrsasha I tried to run the tests. Sugar tests are all failing. I checked your pull, it appears that the sugar code didn't make it completely into your branch.  For ex. the db test helper class is no longer used so the db tables are not being created. Please check.

@skraynick can you check the tests now? I have a somewhat conflicting report - it works if I call them locally, but travis still complains for some reason.

@skraynick everything seems ok now.


Add support for signature subpacket type 6: regular-expression

Hello, it is me again. You may remember me from pull request such as https://github.com/ProtonMail/go-crypto/pull/138.
I noticed when reviewing the issue with the above pull request (https://github.com/ProtonMail/go-crypto/issues/86), it referenced a slightly different issue in the original Go library: https://github.com/golang/go/issues/20686, which is that we're also missing support for Regular Expression packets (which work hand-in-hand with the trust packets), so I thought I would throw that in as well, if you're interested.
The shape of the change is very similar to https://github.com/ProtonMail/go-crypto/pull/138, but I wanted to call out a few design decisions:

The regular expression on the Signature is a *string. Alternatively, we could go with "" being treated the same as a nil value, but unlike the TrustAmount, there was no other value to lean on for a hint of intention.
Signature subpackets can each optionally be critical. It doesn't look like this library has a pattern for preserving the critical flag after parsing it, or allowing the user to indicate whether it is critical. I replicated behavior we had elsewhere and just hard coded this subpacket to critical upon serialization, because that's what I've seen in the wild and also what makes sense to me in this context, but I'm open to looking into a larger change.
The RFC specifies the regex is a null-terminated string, but gpg doesn't appear to expect the string to be null-terminated (the null is shown in the user output, and is not required to parse the outputs). I've followed the RFC, but let me know if you have other thoughts.

Data used for test case:
echo -n "c2bd0410010800310502886e09001621040f0bfb42b3b08bece556fffcc181c053de849bf20385013c0f862a2e6578616d706c652e636f6d000000620603ff7e405020cdbf82ac30f6ad11f82690d3c2fa2107130f80a66fc48a4b6cc426b90585670d8cb8e258f9c1fa35c62381074fd9b740aaebd96a3265c96d145620d7c24265c8e258a2f9a2229e4edb8076e27d5e229cf676135dde4dad54271e061adea05302e81ff412c55742b15c8b20fe3bee4c6b96cd9dfff44da9cc5df328ab" | xxd -r -p | gpg --list-packets
# off=0 ctb=c2 tag=2 hlen=2 plen=189 new-ctb
:signature packet: algo 1, keyid<PHONE_NUMBER>000000
	version 4, created<PHONE_NUMBER>, md5len 0, sigclass 0x10
	digest algo 8, begin of digest 62 06
	hashed subpkt 2 len 4 (sig created 2042-07-14)
	hashed subpkt 33 len 21 (issuer fpr v4 0F0BFB42B3B08BECE556FFFCC181C053DE849BF2)
	critical hashed subpkt 5 len 2 (trust signature of depth 1, value 60)
	critical hashed subpkt 6 len 14 (regular expression: "*.example.com\0")
	data: [1023 bits]

Hey :wave: Thanks for the PR and the detailed design considerations!

The regular expression on the Signature is a *string. Alternatively, we could go with "" being treated the same as a nil value, but unlike the TrustAmount, there was no other value to lean on for a hint of intention.

Hmm. I think we could go either way with this; on the one hand I would say that since an empty regular expression normally matches anything, it's equivalent to the regex not being there, so we could use the empty string. On the other hand, the RFC says:

A regular expression is zero or more branches, separated by |. It matches anything that matches one of the branches.

Which would seem to imply that the empty regex doesn't match anything. I think this might just be an oversight, but to avoid the confusion we could stick with a pointer, yeah.

Signature subpackets can each optionally be critical. It doesn't look like this library has a pattern for preserving the critical flag after parsing it, or allowing the user to indicate whether it is critical. I replicated behavior we had elsewhere and just hard coded this subpacket to critical upon serialization, because that's what I've seen in the wild and also what makes sense to me in this context, but I'm open to looking into a larger change.

Yeah, I think this is reasonable :+1: Since a regex reduces the scope of the signature, it's important that it's understood by the other implementations when using it, so always marking it critical makes sense.

The RFC specifies the regex is a null-terminated string, but gpg doesn't appear to expect the string to be null-terminated (the null is shown in the user output, and is not required to parse the outputs). I've followed the RFC, but let me know if you have other thoughts.

Here I'm even more skeptical of the RFC. Coincidentally I also questioned this on the OpenPGP WG mailing list here, but didn't get any response to that particular question. Do you happen to know what GnuPG or other implementations generate when creating a signature with a regex? If they don't generate a trailing \0, I wouldn't do so here either.

If I create a key using GnuPG, it does appear to append a \0. (GnuPG doesn't let you specify a regex; it just asks for a domain and generates the regex.)
Example:
critical hashed subpkt 6 len 25 (regular expression<EMAIL_ADDRESS>


Add ability to not generate redirects

Is your feature request related to a problem? Please describe.
An enterprise customer wants more control over which paths to create redirects for since they proxy part of the site to an older site on another host but generate part of the site on demand.
Describe the solution you'd like
Customer requested the ability to set an environment variable that tells the plugin not to generate redirects.
Describe alternatives you've considered

delete the generated redirects during build, and generate their own
add customer-defined redirects to the top of the _redirects file during build- the issue with this is that thousands of unused redirects remain in the file

Additional context

https://netlify.zendesk.com/agent/tickets/66088 (internal only)
https://netlify.slack.com/archives/C019VHRUF2M/p1632160200101700 (internal only)

Fixed in v4


Captured arguments are changed by object changes

I found that captured action(or method)'s arguments are changed when I change the object that I passed as argument.
for example,
class A {
  foo(b) {
  }
}

const mockedA = mock(A);
const instanceA = instance(mockedA);
const argument = {};
instanceA.foo(argument);
argument.c = 5;
const [firstArg] = capture(mockedFoo.foo).last();
console.log(firstArg) // print { c: 5 } ! I expected it prints { } because I pass {}.

I guess captured argument should be serialized

But what then if you would like to compare instances?


startingCSV blocks upgrades for dependent operators with nested OperatorGroups

Bug Report
What did you do?
I have 2 operators each with a dependency on a third operator in a single catalog:
A -> C
B -> C
I have two catalogs with these operators (just showing the channels):
catalog1:
docker.io/cdjohnson/testcatalog@sha256:6a7da4528f0f3c46b4d8167733e024d4edf832ab7fcce59c2a3281aa3561c446
schema: olm.channel
package: testoperatora
name: v1.0
entries:
  - name: testoperatora.v1.0.0
---
schema: olm.channel
package: testoperatorb
name: v2.0
entries:
  - name: testoperatorb.v2.0.0
---
schema: olm.channel
package: testoperatorc
name: v3.1
entries:
  - name: testoperatorc.v3.1.1

catalog2:
docker.io/cdjohnson/testcatalog@sha256:bf48512e43435fe9f33e1b0475d5f47276efee8f22ac1e7fa1b7982bd79e51e7
schema: olm.channel
package: testoperatora
name: v1.0
entries:
  - name: testoperatora.v1.0.1
    skipRange: <1.0.1
---
schema: olm.channel
package: testoperatorb
name: v2.0
entries:
  - name: testoperatorb.v2.0.1
    skipRange: <2.0.1
---
schema: olm.channel
package: testoperatorc
name: v3.1
entries:
  - name: testoperatorc.v3.1.2
    skipRange: <3.1.2

Steps:

Apply catalog1
Create subscription for A in AllNamesapces mode (openshift-marketplace)

This creates Subscription C with `spec.startingCSV: C-v3.1.1
This results in A 1.0.0 and C 3.1.1

Create namespace t1
Create OperatorGroup in t1 for t1 (OwnNamespace)
Create subscription for B in namespace t1

This creates Subscription C with `spec.startingCSV: C-v3.1.1
This results in CSV's B 2.0.0 and C 3.1.1

Everything looks good.  Operator A & C is running in the global namespace, and Operator B is running in namespace t1.  Both A and B are depending on the same Operator C.

Apply catalog2

A and C are upgraded in the global namespace to 1.0.1 and 3.1.2 respectively.
B is NOT upgraded to 2.0.1 in namespace t1

At this point, operator B will not upgrade.  No indication of an upgrade is available.
To upgrade:

Edit the automatically generated subscription for operator C in namespace t1 and REMOVE the spec.startingCSV

Once this is done, then Operator B is upgraded.

What did you expect to see?
I would have expected Operator B to be immediately upgraded to 2.0.1.
What did you see instead? Under which circumstances?
Operator B was not upgraded from 2.0.0 to 2.0.1 even though the catalog contained 2.0.1 and the dependency was satisified.
We suspect that this is a problem with the fact that the Automatically generated subscription for Operator C had a startingCSV set and this version no longer existed in the catalog or something similar.
If we use replaces to keep version 2.0.0 of operator C in the catalog, then Operator B is upgraded automatically as expected:
docker.io/cdjohnson/testcatalog@sha256:622be35c67c82481c45253655adb98c723665bc173b341850709b4c0c8cf851b
schema: olm.channel
package: testoperatorc
name: v3.1
entries:
  - name: testoperatorc.v3.1.1
  - name: testoperatorc.v3.1.2
    replaces: testoperatorc.v3.1.1
    skipRange: <3.1.2

Environment

OpenShift version 4.12.7

Possible Solution

Stop creating the startingCSV for automatically generated subscriptions
Ignore the startingCSV when resolving subsequent upgrades.

Additional context

Just a comment to summarize the discussion on Zoom meeting:

startingCSV shouldn't be considered for resolution post-initial-installation. If it is, then that's a bug.
Not sure if this is a resolver bug due to the residual 15 mins delay (sync namespace frequency) on upgrade on the namespace that is not frequently changed. So by upgrading the subscription (removing the startingCSV) you may trigger the namespace sync and then allow the upgrade to happen. Instead of removing the startingCSV, let add an annotation or label to simulate the same namespace sync trigger to see if the upgrade will happen or not.
Gather logs from catalog/olm-operator under debug mode for further diagnosis

I did some testing to validate the discussion points.

Kicking the Subscription by adding an annotation did nothing.

Changing the startingCSV to another non-existent version (1.0.0) did nothing:
time="2023-06-27T16:00:05Z" level=debug msg="error fetching csv listed in subscription status" channel=v3.1 currentCSV=testoperatorc.v3.1.1 error="clusterserviceversions.operators.coreos.com \"testoperatorc.v3.1.1\" not found" id=OIbLU namespace=t1 pkg=testoperatorc source=catalogtest sub=testoperatorc-v3.1-catalogtest-openshift-marketplace
time="2023-06-27T16:00:05Z" level=debug msg="resolving subscriptions in namespace" id=OIbLU namespace=t1
time="2023-06-27T16:00:05Z" level=debug msg="resolution failed" error="constraints not satisfiable: no operators found with name testoperatorc.v1.0.0 in channel v3.1 of package testoperatorc in the catalog referenced by subscription testoperatorc-v3.1-catalogtest-openshift-marketplace, subscription testoperatorc-v3.1-catalogtest-openshift-marketplace exists" id=OIbLU namespace=t1

Changing the startingCSV value to the CURRENT version (3.1.2) fixed it.
time="2023-06-27T16:01:16Z" level=debug msg="error fetching csv listed in subscription status" channel=v2.0 currentCSV=testoperatorb.v2.0.1 error="clusterserviceversions.operators.coreos.com \"testoperatorb.v2.0.1\" not found" id=oXWfd namespace=t1 pkg=testoperatorb source=catalogtest sub=testoperatorb
time="2023-06-27T16:01:17Z" level=info msg=syncing id=tcL4W ip=install-gxd87 namespace=t1 phase=Installing

Summary:
I can workaround the problem by:

Ensuring that the startingCSV of Operator C is in the catalog
Removing the startingCSV

Debug log for the OLM catalog controller:
catalog.log.gz

In the previous test, I also watched the CSV in namespace t1:
> oc get csv -n t1 -w
NAME                   DISPLAY           VERSION   REPLACES   PHASE
testoperatora.v1.0.0   Test Operator A   1.0.0                Succeeded
testoperatorc.v3.1.1   Test Operator C   3.1.1                Succeeded
-- Install B in t1 --
testoperatorb.v2.0.0   Test Operator B   2.0.0
testoperatorb.v2.0.0   Test Operator B   2.0.0
testoperatorb.v2.0.0   Test Operator B   2.0.0                Pending
testoperatorb.v2.0.0   Test Operator B   2.0.0                Pending
testoperatorb.v2.0.0   Test Operator B   2.0.0                Pending
testoperatorb.v2.0.0   Test Operator B   2.0.0                InstallReady
testoperatorb.v2.0.0   Test Operator B   2.0.0                Installing
testoperatorb.v2.0.0   Test Operator B   2.0.0                Installing
testoperatorb.v2.0.0   Test Operator B   2.0.0                Installing
testoperatorb.v2.0.0   Test Operator B   2.0.0                Succeeded
-- Update the catalog with new versions of A,B,C --
testoperatorc.v3.1.2   Test Operator C   3.1.2     testoperatorc.v3.1.1
testoperatorc.v3.1.2   Test Operator C   3.1.2     testoperatorc.v3.1.1   Pending
testoperatorc.v3.1.1   Test Operator C   3.1.1                            Replacing
testoperatorc.v3.1.1   Test Operator C   3.1.1                            Replacing
testoperatora.v1.0.0   Test Operator A   1.0.0                            Succeeded
testoperatora.v1.0.1   Test Operator A   1.0.1     testoperatora.v1.0.0
testoperatora.v1.0.1   Test Operator A   1.0.1     testoperatora.v1.0.0   Succeeded
testoperatorc.v3.1.2   Test Operator C   3.1.2     testoperatorc.v3.1.1   Succeeded
-- Update the C subscription startingCSV to 3.1.2 --
testoperatorb.v2.0.1   Test Operator B   2.0.1     testoperatorb.v2.0.0
testoperatorb.v2.0.1   Test Operator B   2.0.1     testoperatorb.v2.0.0
testoperatorb.v2.0.0   Test Operator B   2.0.0                            Replacing
testoperatorb.v2.0.1   Test Operator B   2.0.1     testoperatorb.v2.0.0   Pending
testoperatorb.v2.0.1   Test Operator B   2.0.1     testoperatorb.v2.0.0   Pending
testoperatorb.v2.0.1   Test Operator B   2.0.1     testoperatorb.v2.0.0   InstallReady
testoperatorb.v2.0.1   Test Operator B   2.0.1     testoperatorb.v2.0.0   Installing
testoperatorb.v2.0.1   Test Operator B   2.0.1     testoperatorb.v2.0.0   Installing
testoperatorb.v2.0.1   Test Operator B   2.0.1     testoperatorb.v2.0.0   Installing
testoperatorb.v2.0.1   Test Operator B   2.0.1     testoperatorb.v2.0.0   Succeeded
testoperatorb.v2.0.0   Test Operator B   2.0.0                            Deleting
testoperatorb.v2.0.0   Test Operator B   2.0.0                            Deleting

Apology in advance for a long comment here but I just noticed the OperatorGroup (OG) implication here.

If the operator C is installed a namespace with AllNamespaces mode, that it is a singleton (global) operator. There shouldn't be a second instance of that operator anywhere else. Hence, the secondary operator C instance in t1 namespace shouldn't be allowed. You end up with 2 different instances of the same operator that will reconcile custom resources twice if they are created in t1 namespace. This issue should be detected by OG controller though I'm not sure if it should prevent the resolution or simply prevent the installation.
The current resolver doesn't take into account operator-scoping so it doesn't see copiedCSV (which is the manifestation of operator-scoping) as a valid CSV. This is a known limitation of the current resolver. As far as the resolver is concerned, multi-tenant is not its problem as it only does namespace-scoped resolution. So in this scenario, the resolver tries to resolve the subscriptions in t1 namespace and comes up Operator B and Operator C and installed them. By doing so, it probably overwrote the copiedCSV from Operator C from marketplace namespace.  Then when the upgrade happens, the resolver doesn't see the current CSV anymore so it will assume this is initial installation and take startingCSV into account. However, given you are using sparing catalog which no longer includes the version that is listed in startingCSV which leads to the upgrade is stuck as it can't find the version in startingCSV.
Even if the trick of "removing startingCSV" works, I'm concerned that this is technically violating the current multi-tenant model that OLM is using. Furthermore, you will need to do it everytime for new installation given the resolver will continue to assign startingCSV as a part of its dependency resolution.
I consider it is a flaw/bug or lacking of controlling logic that leads to this installation being possible. There should be a logic somewhere in OG controller or somewhere to prevent this from happening.

@dinhxuanvu
Yes, you're correct that operator C is a singleton.  Operator C is NOT installed a second time, however... At least the deployment isn't created
From our observations:

Operator A and C CSVs are copied and modified/decorated into namespace t1.
When Operator B is installed in t1, the auto-generated Subscription for C is created, but the existing CSV is used (not re-created) and the operator is not provisoned a second time (from what I can tell)

We were told that the "nesting" model vs. the "intersection" model was supported.... At least in the All/Own use case.  So, for example, you could have a multi-tenant operator dependency (OWN) on a singleton operator (ALL).  My understanding was that the Subscription had some understanding of the copied CSV and didn't attempt to re-create it.
I do realize that this is complex and the whole reason why OperatorGroups are being abandoned in OLM v1.
It sounds like the recommendation here is to NOT use OLM Dependencies when it's possible that they may span operator groups and instead use nativeAPIs in the CSV to at least check that the CRD is present.

Operator A and C CSVs are copied and modified/decorated into namespace t1.
When Operator B is installed in t1, the auto-generated Subscription for C is created, but the existing CSV is used (not re-created) and the operator is not provisoned a second time (from what I can tell)

As far as I know, the resolver doesn't see the copiedCSV as the current CSV cache is ignoring copied CSV while populating. So it is more likely that the resolver will attempt to install a new CSV. You can observe this by watching the new CSV if it is copied or new (the copied one should have a label for that).

We were told that the "nesting" model vs. the "intersection" model was supported.... At least in the All/Own use case. So, for example, you could have a multi-tenant operator dependency (OWN) on a singleton operator (ALL). My understanding was that the Subscription had some understanding of the copied CSV and didn't attempt to re-create it.

This was the behavior of the old old resolver where there were a separation process for installing and upgrade and both were more intertwined with other resources reconciliation process. The new resolver is more discrete and independent than that. However, I do recall the OG controller should prevent at least the installation part of this (InstallPlan execution step). Perhaps, that's why you didn't see any deployment for operator C on that namespace.
Either way, as I said, this multi-tenant situation doesn't bode well for your use case. So approaching this differently is certainly the way to go. You can try to use nativeAPIs which is rarely used but it may work.

/close


PEAR-1852: Fix for cDAVE - Survival plot resets what is plotted when switching from days to years (or vice-versa)

Description
Checklist

[N/A] Added proper unit tests
[N/A] Left proper TODO messages for any remaining tasks
[N/A] Scanned for web accessibility with aXe, and mitigated or documented
flagged issues

Screenshots/Screen Recordings (if Appropriate)

looks good 👍


IMPORTANT! Volvo Energy API is down

Seems volvo block this way?
i did a call on https://developer.volvocars.com/apis/energy/v1/specification/ and seems it got a 404 back for the call.

seems api.volvocars.com is down atm

Just when I wanted to start to checkout this API 🤣 :

ow nice! didn't saw that bar xD

API Down status 😂

Well... the bar is gone but it's still not working with my PS2 VIN. I guess they patched the hole 🙈

I suppose they check that the VIN belongs to one of the accounts. but I don't see any way to link a non-volvo Vin to a Volvo account.
Yesterday I also sent a mail to polestar developer. let's see if they want to reply on my mail

the only thing that i see what we can do is finding documentation about this URL:
https://pc-api.polestar.com/eu-north-1/mesh/
that URL is normally used on the polestar app (after reverse engineering)

that URL is normally used on the polestar app (after reverse engineering)

i know, thats not part of this discussion - but did you manage to get around the cert pinning of the app?

not from  the app, but somewhere else i found a the cert..
i'm try now to check if i can connect on it.

so far what i got
it uwe graphql
i got the url where we api call will be done
https://pc-api.polestar.com/eu-north-1/mesh/
content should be operationName and Query, but what the graphql should be is now guessing

Do you get anything with query
query Cars {
  cars {
    carModels {
      id
    }
  }
}

this should be valid full query, but I get invalid JSON error, which may be authorization or some other issue
query CarModels {
  cars {
    __typename
    carModels {
      __typename
      ...CarModelDetails
    }
  }
}
fragment CarModelDetails on CarModel {
  __typename
  id
  title
  tagline
  headerImageInEnvironmentAsset {
    __typename
    url
  }
  defaultConfiguration {
    __typename
    ...CarConfigurationDetails
  }
  themes {
    __typename
    ...CarConfigurationDetails
  }
}
fragment CarConfigurationDetails on CarConfiguration {
  __typename
  id
  imageAsset {
    __typename
    url
  }
  gallery {
    __typename
    url
  }
  title
  subTitle
  body
  isBaseModel
  configuratorUrl
  visible
  enabled
  configurationCtaText
}

Ive seen the following when pairing the google home app to polestar
Some of these scopes might help
https://polestarid.eu.polestar.com/PolestarLogin/approval?resumePath=<>&cSRFToken=8WG0U7sK9goIkekHytNa&userName=<>@gmail.com&scopes=%5B%22vehicle:unlock%22,%22vehicle:climatization%22,%22vehicle:engine_start%22,%22vehicle:engine%22,%22vehicle:doors_status%22,%22vehicle:lock_status%22,%22vehicle:engine_status%22,%22vehicle:fuel_status%22,%22vehicle:climatization_status%22,%22vehicle:lock%22%5D&client_id=polGoogleAssistantRVA&client_name=Google%20Assistant%20for%20Polestar

You can now see SoC and odometer on the polestar website. Maybe this is another option?!

You can now see SoC and odometer on the polestar website. Maybe this is another option?!

URL for this?

Log in and head to the 'Cars' page in your profile - https://www.polestar.com/au/login/cars - select your car and it'll be shown there.
On 16 Dec 2023, at 08:37, Peter @.***> wrote:

You can now see SoC and odometer on the polestar website. Maybe this is another option?!
[image]https://private-user-images.githubusercontent.com/39953358/290939283-ff281607-1742-4291-9f9b-0cef0d837d88.jpeg?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTEiLCJleHAiOjE3MDI2NzY0NTcsIm5iZiI6MTcwMjY3NjE1NywicGF0aCI6Ii8zOTk1MzM1OC8yOTA5MzkyODMtZmYyODE2MDctMTc0Mi00MjkxLTlmOWItMGNlZjBkODM3ZDg4LmpwZWc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBSVdOSllBWDRDU1ZFSDUzQSUyRjIwMjMxMjE1JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDIzMTIxNVQyMTM1NTdaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT03OGIwN2FiZTI1YzhjNzIxYWY0NjEwOTVkYjlkNjI0OGMzYTdkNzg0MmNlMzE2MzE0ZmI4YTJhMDk5MGRkNjk2JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.MPibk3-LX12cAvOrez46MgxMYZLq56q9A56F_eQK5Qk
URL for this?
—
Reply to this email directly, view it on GitHubhttps://github.com/leeyuentuen/polestar_api/issues/10#issuecomment-1858518199, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AABTXMOUODN4KG7RC6YYBRTYJS7I3AVCNFSM6AAAAAA7TCO35KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJYGUYTQMJZHE.
   TokenRevokeResponse
  setConsent(consent: Boolean!, displayName: String, termsAndConditionVersion: String, market: String!): Boolean
  addFavorite(psid: String!): Boolean
  removeFavorite(psid: String!): Boolean
  saveCart(orderId: String, cart: InputCart!): SaveCartResponse
  updateConsumer(body: MutationableConsumer!): ConsumerUpdateResponse
  createFleetRequest(body: FleetCase!): CreateFleetResponse
  createLeadRequest(body: LeadCase!): CreateLeadResponse
  createCaseRequest(body: SupportCase!): CreateCaseResponse
  createGDPRRequest(body: SupportCase!): CreateCaseResponse
  createCancellationRequest(body: CancellationCase!):  Token
  getConsumer(id: String): Consumer
  introspectToken(token: String!): IntrospectResponse
  hello(message: String): String
  getUserLeaderboard(market: String!, filter: UserFilter!, limit: Int, skip: Int, name: String, onlyFavorites: Boolean): UserLeaderboard!
  getConsent: Consent
  getCountryLeaderboard(market: String!, filter: CountryFilter!, searchValue: String): CountryLeaderboard!
  getMarkets(marketNames: [String]): [Market]
  markets(marketNames: [String]): [Market]
  market(marketName: String, locale: String, cmsLocale: String): Market
  getBatteryData(vin: String!): Battery
  getOdometerData(vin: String!): Odometer
  getConsumerCars: [Car]!
  getConsumerCarsV2(locale: String): [VehicleInformation!]!
  getConsumerCarsByVin(vin: [String]!): [CarInformation]
  getCart(market: String): GetCartResult
  getConfiguration(orderId: String!): LoadResponse
  getDocumentMetadata(input: GetDocumentMetadataRequest!):

Looks very promising.

So did you solve the authorization challange?

So did you solve the authorization challange?

yes, found a way to get the access_token
i'll release over few days a dirty alpha version.

just a quick question, since today, the odo meter became 0, yesterday it was still the KM,
can someone else also confirm?

there is no change or reset in my account

Shows fine on mine too.

https://github.com/andysmithfal/polestar.js
Checkout this. I tested it, and it works without any client creds and just personal user/pw.

let start with a dirty release
https://github.com/leeyuentuen/polestar_api/releases/tag/1.0.0-alpha

Works like a charm!

Works like a charm!

do you have correct trip meter value and odometer value? for me, yesterday it works, but today it show strange values

Yes,
Both are looking good:

Yes,
Both are looking good:

let me know tomorrow if the value is still like that,

https://github.com/andysmithfal/polestar.js
Checkout this. I tested it, and it works without any client creds and just personal user/pw.

Looking at that solution, I don't see a need to generate a Volvo Developer Account any longer. The app seems to mimic the Polestar web-site acting as client.
Do you agree?

https://github.com/andysmithfal/polestar.js
Checkout this. I tested it, and it works without any client creds and just personal user/pw.

Looking at that solution, I don't see a need to generate a Volvo Developer Account any longer. The app seems to mimic the Polestar web-site acting as client.
Do you agree?

my current one is just using polestar username and password and vin. It is not using volvo developer account. (readme at frontpage need to be updated)

Can I advise we split the API file into it's own separate library for future integration into HA as official integration :) ?

Can I advise we split the API file into it's own separate library for future integration into HA as official integration :) ?

I'd love to see an official integration, as I don't use HA OS or HACS (just the plain container image).  But that should be a dedicated ticket / feature request.

Can I advise we split the API file into it's own separate library for future integration into HA as official integration :) ?

most of the code is in a separated polestar_api.py file.

I support several official integrations, if you would like my help, I can refactor the current file into a separate library and work with you all on an official integration.
Answering @m0wlheld official integration means it gets distributed in the core of the project (we don't need any add-on)

Answering @m0wlheld official integration means it gets distributed in the core of the project (we don't need any add-on)

Correct. I can contribute German translation and have a Polestar on my own, so I can do testing as well.

https://github.com/andysmithfal/polestar.js
Checkout this. I tested it, and it works without any client creds and just personal user/pw.

Looking at that solution, I don't see a need to generate a Volvo Developer Account any longer. The app seems to mimic the Polestar web-site acting as client.
Do you agree?

my current one is just using polestar username and password and vin. It is not using volvo developer account. (readme at frontpage need to be updated)

That is great to hear! My question would be if you can still query every VIN or just the VIN in your Polestar account? I guess this was the reason for Polestar to shutdown the previous way.

https://github.com/andysmithfal/polestar.js
Checkout this. I tested it, and it works without any client creds and just personal user/pw.

Looking at that solution, I don't see a need to generate a Volvo Developer Account any longer. The app seems to mimic the Polestar web-site acting as client.
Do you agree?

my current one is just using polestar username and password and vin. It is not using volvo developer account. (readme at frontpage need to be updated)

That is great to hear! My question would be if you can still query every VIN or just the VIN in your Polestar account? I guess this was the reason for Polestar to shutdown the previous way.

you can only query the vin that is linked to your Polestar account.
in theory, I can use it without config flow, and let the integration search for the VIN in the polestar account (maybe a feature for the next release)

I support several official integrations, if you would like my help, I can refactor the current file into a separate library and work with you all on an official integration.
Answering @m0wlheld official integration means it gets distributed in the core of the project (we don't need any add-on)

this is a good opportunity, maybe let me first make sure that this run stable before we refactor them?

just installed. its working well!

confirmed, works. did anybody else notice this yet?
do you have correct "trip meter" value and "odometer" value? for me, yesterday it work, but today it showed strange values (maybe I fetch too much?)

even on polestar app, my odo meter is set as 0km

I'll close this ticket,
the code has been merged to master because the current master version doesn't work.
for issue, open new issue to get better overview
Know issue:

cleanup old code
use refresh token


feat(cmd-api-server): swagger.json endpoints

fixes: #1877
Signed-off-by: charellesandig<EMAIL_ADDRESS>

Just one question here. @petermetz do we also need to have to patch our test cases with relevant code, to include testing of this endpoint as well?

@jagpreetsinghsasan Yes, there will have to be test coverage for these endpoints as well but I don't want to get into that yet because we are still working out the fundamental acceptance criteria such as re-usability (see my submitted change request above for details).

Note to self: These are the crash logs for the two jobs that are timing out for some reason. It's likely a bug with the plugin registry initialization logic of the API server that was changed a little bit to make it more flexible (more flexible = more bug prone as usual...)
2023-09-14T20-29-18-cacti-ci-crash-2.log
2023-09-14T20-29-18-cacti-ci-crash.log


Pandas .append method deprication

nfl.import_pbp_data give the warning below. Should update method to use concat rather than append method.
FutureWarning: The frame.append method is deprecated and will be removed from pandas in a future version. Use pandas.concat instead.
plays = plays.append(raw)

Fixed in v0.2.8.


feat: add comments/typedocs to most commonly used functions

This is a feature request
Problem

Most of the functions used by builders do not have any comments/JSDocs added to them. These can be useful for learning about how the library works without leaving a code editor or the codebase.
Proposed Solutions

Add comments/typedocs to the most commonly used functions including:

functions to create encoder/decoder
functions to create a filter subscription
functions to push messages to light push

Notes

It makes sense to wait for first minor/major release to add this

Closing issue, based on feedback in conversation with hackathon participants, they have signaled that examples of implementations are more useful than comments in the code.

Already present:

https://js.waku.org/functions/_waku_core.createDecoder.html
https://js.waku.org/functions/_waku_core.createEncoder.html

Indeed I can't find createSubscription in the docs. @danisharora099 to ensure it's documented as you update the API
some for light push, it's probably hidden in the code.


FLPATH-340: propertyPath in update parameter response

What this PR does / why we need it:
user needs to return propertyPath for dynamic parameters update.  Validation on  the parameters and propertyPath  is also needed for UI
Which issue(s) this PR fixes :
Fixes #FLPATH-340
Change type

[ ] New feature
[x] Bug fix
[x] Unit tests
[ ] Integration tests
[ ] CI
[ ] Documentation
[ ] Auto generated SDK code

Impacted services

[x] Workflow Service
[ ] Notifivcation Service

Checklist

[ ] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.

/approved

/lgtm


pow not implemented

iv = intvar(0,9)
m = Model( iv**2 > 0 )
m.solve()

NotImplementedError: Not a know supported ORTools left-hand-side 'pow' ((IV0) pow 2) == (IV1)
OR-tools does not have a power operator, it should be translated into iv*iv (for the appropriate power)

Fixed in 5eefcfcdb4063af0634d60b186d669868d0efa08


Rename local variables to avoid collisions with package names

golint is issuing some warnings about local variable names colliding with imported package names. Are you interested in getting rid of those warnings by renaming the local variables?
(Or maybe rename the cmd package to the longer command, and preserve cmd as a local variable name?)

Yeah, golint (with offenses causing a CI error) in the CI sounds like a good idea.
Would you like me to look at adding it to the Travis CI configuration as part of this PR?

Well, shucks. From the golint README:

Golint is not perfect, and has both false positives and false negatives. Do not treat its output as a gold standard. We will not be adding pragmas or other knobs to suppress specific warnings, so do not expect or require code to be completely "lint-free". In short, this tool is not, and will never be, trustworthy enough for its suggestions to be enforced automatically, for example as part of a build process.

So we probably won't be able to get to a fully-clean baseline. That probably rules out using it as a CI check.


Configurable frame IDs in trajectory_comparison_main.cc

Fixes also the other flag descriptions.

@wally-the-cartographer merge


Make it more difficult to use the testnet SDK with mainnet LWD

It is still technically possible to connect to a server on the wrong chain. In the past, this was prevented by letting the SDK choose the server by default but, nowadays, developers are expected to run their own servers. This means that the SDK needs to be more defensive in the way that it manages data.
Criteria:

testnet checkpoints cannot be used with mainnet lightwalletd servers and vice-versa.
if the SDK is in testnet mode it rejects servers that are on the wrong chain
developers can override this behavior with error handler callbacks
[optional] expose properties in the SDK that allow the developer to inspect whether the local data is mainet and whether the server is mainnet

Test cases:

create a wallet with a testnet checkpoint, then point it to a mainnet server
create a wallet with a mainnet checkpoint, then point it to a testnet server
sync a wallet on mainnet, then relaunch the app, pointing to testnet
sync a wallet on testnet, then relaunch the app, pointing to mainnet

I think this is done

This is ensured by CompactBlockProcessor.verifySetup. And the new server switching logic, as defined in #1406, adds Synchronizer.validateServerEndpoint.


Delete unused code

For information: If I create the file schema.rb after migration, then the attribute for strings "limit: 255" is not made. This regularly leads to annoying merge conflicts. Can we handle this?

@sabrina-ulbrich Since the PR for adding the websites ( https://github.com/rubymonsters/speakerinnen_liste/pull/723 ) is merged, there are some merge conflicts with master now.

@tyranja can we solve the merge conflicts together? I feel doubtful when I am alone with that.

@sabrina-ulbrich Sorry, did not see your comment. I have to turn the notifications back on. But it looks like you have done it :tada:

Should I press the great green merge button or does anybody want to have a look at the code, @zaziemo @tyranja ?

Can we delete that line:  include AutoHtml in the beginning of the profile model as well?

other than that, it looks :+1:

@tyranja Yes, done it. It seems to belong to the medialink class now.

Yes, do it :)


ImageUpdateAutomation not working bacause of git clone error

I am using github enterprise as gitRepositorySource in ImageUpdateAutomation.
image-automation-controller image : ghcr.io/fluxcd/image-automation-controller:v0.14.0
git source configuration:
apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: GitRepository
metadata:
  name: k8source-demo
  namespace: flux-system
spec:
  interval: 5m0s
  ref:
    branch: master
  secretRef:
    name: flux-system
  url: https://GHE-url

imageupdateAutomation configuration :
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageUpdateAutomation
metadata:
  name: k8-auto-update
  namespace: flux-system
spec:
  interval: 1m0s
  sourceRef:
    apiVersion: source.toolkit.fluxcd.io/v1beta1
    kind: GitRepository
    name: k8source-demo
  git:
    checkout:
      ref:
        branch: master
    commit:
      author:
        email<EMAIL_ADDRESS>        name: fluxcdbot
      messageTemplate: 'updated image'
    push:
      branch: feature/auto-update
  update:
    path: ./cluster
    strategy: Setters

I am getting following error while enabling it.
$ flux get image update k8-auto-update
NAME         READY   MESSAGE                                                                                LAST RUN        SUSPENDED
k8-auto-update False   unable to clone 'GHE url', error: server requires authentication that we do not support                     False

I have used ghe-auth-token as secret in source. This source configuration perfectly works for kustomizations for deployments on k8 clusters whereas when I am using it in imageupdateAutomation it is failing with above error.
Could you please suggest any solution to this? or may be point out what is wrong here?

@AshuDubey91 thank you for reporting this. The last few months we have made several changes to the way we connect to git repositories. I believe image-automation controller version v0.21.0 may resolve your issue as it upgrades out libgit2 implementation to version 1.3.0.
This will require a redeploy of all components so I would recommend doing so via flux bootstrap using the flux cli version v0.28.0 which will be released tomorrow.
Can you test it again with the version above and let us know how you get on please?

We have extensively increased our test coverage in the last while, which leads me to think this is no longer a problem.
Closing for lack of activity, happy to reopen in case of further reports of the controller not being able to clone GitHub Enterprise repositories.


[BUG]  $redis->script('load', $script) 返回 bool(true)

Darwin JasoniMac.local 21.3.0 Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_X86_64 x86_64
PHP 8.0.23 (cli) (built: Sep  4 2022 09:20:50) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.23, Copyright (c) Zend Technologies
    with Zend OPcache v8.0.23, Copyright (c), by Zend Technologies
Composer could not find a composer.json file in /Users/jasonhe
To initialize a project, please create a composer.json file. See https://getcomposer.org/basic-usage

hyperf 版本:
"require": {
          "php": ">=8.0",
          "hyperf/cache": "~2.2.0",
          "hyperf/command": "~2.2.0",
          "hyperf/config": "~2.2.0",
          "hyperf/db-connection": "~2.2.0",
          "hyperf/framework": "~2.2.0",
          "hyperf/guzzle": "~2.2.0",
          "hyperf/http-server": "~2.2.0",
          "hyperf/logger": "~2.2.0",
          "hyperf/memory": "~2.2.0",
          "hyperf/process": "~2.2.0",
          "hyperf/redis": "~2.2.0"
      },

以前一直是返回 lua script 的哈希值，现在返回 bool(true)
新建立了一个空的 hyper-skeleton 工程重现
$redis = $container->get(RedisFactory::class)->get('default');
$result = $redis->script('load', 'return "hello"');
var_dump($result);

用的是KVRocks, 发现是后台数据库KVRocks 2.1.0的问题，换成Redis就返回正常的哈希值


Fix large cpu consumption in snowboy detect

Hello.
Current code collect really large buffer and put in snowboy detect every time where new chunk reading, without clearing. This create large cpu consumption - 80-85% on my orange pi.
I change it, using an algorithm similar to snowboydecoder.py (put smaller buffer and clear after). This decrease cpu usage to 4%.
I use similar code on my project and this works without problems.

Thanks for the patch! Looks good.


Fix apparent logic error in file output stream implementation. [phab:D782]

Created by pcc at 2016-03-20 12:00:44:
We were previously testing whether MergeDownIfTooSmall returned false to
determine whether a buffer was merged. This was wrong; MergeDownIfTooSmall
returns true if a buffer was merged. As a result, we were never moving buffers
onto the free list by popping them off the stack. This change fixes the sense
of the test, resulting in a reduction in memory consumption of about 300%
in one of LLVM's largest TUs.

zarko accepted this revision at 2016-03-21 19:16:59

zarko closed via commit 7adffb1da5140ea689bbb20a13d7ab0d30c6e8a6 at 2016-03-21 19:17:42


Add reading/writing error check

Escapes from hanging if USB cable (Joy con charging grip, Pro controller) is removed
a Joy-Con is removed from grip or
Bluetooth connection times out or has other connection problems.
Basically a mechanism to force the user to start again and have legit results.
The 2000 tries are calculated based on 16ms x2 (send/read back latency), so it can try for aprox. a minute.
If BT/USB connection is completely dropped, it will escape instantly.
(BTW, 2 more pull requests left from my research. Async dual dumping and some cosmetic stuff)

LGTM


Lambda Resolver - Top Level Errors not being logged in amplify mock

Note: If your issue/bug is regarding the AWS Amplify Console service, please log it in the
Amplify Console GitHub Issue Tracker

Describe the bug
When requiring an invalid package, the function will simply timeout with no indication of what the error is.
Amplify CLI Version
4.41.0
To Reproduce

In your lambda resolver, provide an invalid require statement before the handler is defined.
Run amplify mock
Execute the graphql query/mutation that uses said lambda resolver

Expected behavior
Print the error in the console and fail. Not timeout.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: Windows
Node Version: v12.16.1

The fix for this has been released in the latest version of the CLI. Please upgrade to the latest version to try it out.


Improve InputStream and OutputStream copying

Description

This merge request introduces improvements to the stream copying functionality. The existing static method has been refactored to use a dynamic buffer size and take advantage of try-with-resources for automatic stream closure and avoid using of while(true). These changes enhance the clarity and maintainability of the code.
Motivation and Context

This merge request addresses the need to improve the efficiency and clarity of stream copying operations within the codebase.

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have added tests to cover my changes.

:+1:


KAFKA-14015: StandaloneHerder::restartConnector should reconfigure tasks if configs have been changed

https://issues.apache.org/jira/browse/KAFKA-14015: A config provider (https://cwiki.apache.org/confluence/display/KAFKA/KIP-297%3A+Externalizing+Secrets+for+Connect+Configurations) that has dynamic reloading of secrets doesn't work as expected when Connect is run in standalone mode - i.e. tasks continue running with an older secret config value when the secret is rotated.
When a config provider needs to inform the herder that a connector needs to be restarted due to a change in a secret config that needs to be propagated to the connector and its tasks - it calls Herder::restartConnector
In the DistributedHerder implementation of restartConnector this works as expected where the connector is stopped, then started, and then if it's in the STARTED state at the end of startup - a task reconfiguration is requested. A task reconfiguration involves asking the connector to return a list of task configs (using the latest connector configs), comparing it with the running task configs and if a change is detected - write the new set of task configs to the config topic which will eventually result in the old set of tasks being stopped and a new set of tasks being brought up.
In the StandaloneHerder implementation, however, the step of requesting task reconfiguration is missing. This PR aims to fix this which should solve the issue in https://issues.apache.org/jira/browse/KAFKA-14015

@C0urante @vamossagar12 could you please take a look at this whenever you get a chance? Thanks!


[duktape] Replace the old way of using the port

Fixes https://github.com/microsoft/vcpkg/issues/35308

Replace the old usage added in 2019 with the currently preferred usage.
duktape only has one downstream, which is dukglue, and dukglue is also a header-only port.

Usage passed with following triplets:
x64-windows
x64-windows-static

[x] Changes comply with the maintainer guide
[ ] SHA512s are updated for each updated download
[ ] The "supports" clause reflects platforms that may be fixed by this new version
[ ] Any fixed CI baseline entries are removed from that file.
[ ] Any patches that are no longer applied are deleted from the port's directory.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

Again, IMO there should be a grace period for customers which use the old CMake config name.

Thank you for your comment.
Could you please elaborate on what a grace period means? Are you referring to providing a method for users to transition from the old usage to the new usage?

Duplicate of https://github.com/microsoft/vcpkg/pull/35813