Skip to content

[MOB-16678] Handle edge network location hint response#259

Merged
kevinlind merged 23 commits intoadobe:devfrom
kevinlind:mob-16678-region-id
Sep 8, 2022
Merged

[MOB-16678] Handle edge network location hint response#259
kevinlind merged 23 commits intoadobe:devfrom
kevinlind:mob-16678-region-id

Conversation

@kevinlind
Copy link
Copy Markdown
Contributor

Description

Handle the EdgeNetwork location hint response from Konductor.

Reads location hint and ttl from Konductor response and stores in EdgeProperties. All requests from the Edge extension will include the location hint in the request URL if available and if not expired. The location hint and expiry date (calculated from the ttlSeconds) is persisted in User Defaults and loaded once the Edge extension launches.
The Edge extension now creates a shared state which includes just the location hint. A shared state is created on launch of the extension and when ever the location hint value changes. A shared state is not created, however, if only the expiry date is updated but the hint value doesn't change.

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

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

Checklist:

  • I have signed the Adobe Open Source CLA.
  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

// else keep consent pending until the consent preferences update event is received

// TODO - Always set state or only when properties are not empty ???
createSharedState(edgeProperties.toEventData(), nil)
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Always creates a shared state when EdgeState boots, regardless of location hint value. Another option is to only create the shared state if there is a valid location hint value, but I think creating an initial empty shared state on boot is better approach and more consistent with how other extensions are implemented.

// lower event numbers than states using nil. If this extension later needs to create shared
// states from received events, then this code must be refactored to also use received
// events as the state version.
createSharedState(self.edgeProperties.toEventData(), nil)
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm using nil here for the shared state version, which will cause the Event Hub to get the next available version number. I'm using nil because this function is called by the NetworkResponseHandler which does not have a triggering event to create a shared state with. Using nil here means I must always use nil when creating a shared state even when I have one available (such as in bootupIfNeeded). The shared state is created mainly for Rules use-cases where a customer may want to build a postback URL using the location hint.

Another option is for NetworkResponseHandler to dispatch an event which is listened for by Edge to handle the location hint. That way there is an event to use to create the shared state. This is how Identity Direct extension handles this case. This option, however, will cause a delay when the location hint is handled and any queued hits will not include the hint in their URLs.

As there are not current plans for Edge to include other properties in it's shared state, I feel the first option of using 'nil' is the better approach, but I wanted to point this out to hear other's thoughts.

@kevinlind kevinlind requested review from addb and praveek August 30, 2022 00:08
@codecov
Copy link
Copy Markdown

codecov bot commented Aug 30, 2022

Codecov Report

Merging #259 (9e55759) into dev (ebffb92) will increase coverage by 2.91%.
The diff coverage is 99.22%.

@@            Coverage Diff             @@
##              dev     #259      +/-   ##
==========================================
+ Coverage   92.54%   95.45%   +2.91%     
==========================================
  Files          27       28       +1     
  Lines        1032     1143     +111     
==========================================
+ Hits          955     1091     +136     
+ Misses         77       52      -25     

build-and-test:
macos:
xcode: 12.0.1 # Specify the Xcode version to use
xcode: 13.4.0 # Specify the Xcode version to use
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the code coverage issue fixed in 13.4?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not seeing an issue with CodeCov. I've updated the version because version 12 of Xcode is no longer supported in CircleCI. The builds just fail now. Their documentation states that they support the latest 4 major.minor versions of Xcode. We've used Xcode 13.0.0 for other projects, but that is the 4th version. If there is a 13.5 version of Xcode, then 13.0.0 may not be supported. I didn't want to bump all the way to Xcode 14, so I picked that latest Xcode 13 image supported by CircleCI.

}

enum LocationHint {
static let SCOPE = "scope"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add the "locationHint" constant here only?
static let KEY = "locationHint"

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain further? I guess I don't understand the question.

Copy link
Copy Markdown
Contributor

@addb addb Sep 7, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This approach is also fine. I was wondering if changing the location of the constant makes sense.
nit:
Instead of Edge.LOCATION_HINT -> we have it as LocationHint.KEY

private func setLocationHint(hint: String?, ttlSeconds: TimeInterval?) {
guard let state = state else { return }
if let hint = hint, let ttlSeconds = ttlSeconds {
state.setLocationHint(hint: hint, ttlSeconds: ttlSeconds, createSharedState: createSharedState(data:event:))
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do other extensions use the locationHint from the shared state?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not currently and it's not expected as they should send requests through the Edge extension. The shared state is intended for Rules use cases where a customer may want to send a postback directly to the Edge Network. There's no hard requirement for that use-case either, however.

} else {
handleStoreEventHandle(handle: eventHandle)
if let type = eventHandle.type {
if EdgeConstants.JsonKeys.Response.EVENT_HANDLE_TYPE_STORE == type.lowercased() {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Is type.lowercased() required? Calling it only for if condition is little confusing.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's required as the response uses "state:store" (lowercased). However, the original code used it so I preserved the logic. The handle type "locationHint:result" is mix cased so I'm doing an exact match.

@@ -74,4 +93,57 @@ class EdgeState {
currentCollectConsent = status
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not related to your PR but some of the variables are not guarded by DispatchQueue and this could cause race conditions and crashes.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've updated EdgeState to guard the consent status. It's better to do it as it keep the design consistent, however I don't think the consent status is accessed from multiple threads. Can you take another look at this part of the PR?

Copy link
Copy Markdown

@praveek praveek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

@kevinlind kevinlind merged commit 03096b0 into adobe:dev Sep 8, 2022
@kevinlind kevinlind deleted the mob-16678-region-id branch September 8, 2022 17:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants