OpenSea - update to v2 of api #15112
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 3 Skipped Deployments
|
WalkthroughThe pull request introduces significant improvements to the OpenSea integration, focusing on enhancing the API interaction methods. Key changes include the addition of a new private method Changes
Assessment against linked issues
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (3)
components/opensea/opensea.app.mjs (1)
8-10: Consider making the base URL configurable
The_baseUrl()method currently returns a hardcoded string. For better flexibility (e.g., testing or support for multiple environments), consider making this fully or partially configurable, possibly through an environment variable.components/opensea/sources/new-collection-events/new-collection-events.mjs (2)
20-23: Validate the new “collectionSlug” prop
RenamingcontractAddresstocollectionSlugclarifies the requirement. However, consider validating or sanitizing the input to account for incorrect slugs or unexpected special characters.
33-39: Confirm timestamp format
generateMeta()sets thetsfield toitem.protocol_data.parameters.startTime. If this is not an integer Unix timestamp, downstream consumers may misinterpret it. Consider parsing, converting, or clarifying the expected format.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (3)
components/opensea/opensea.app.mjs(1 hunks)components/opensea/package.json(1 hunks)components/opensea/sources/new-collection-events/new-collection-events.mjs(2 hunks)
🔇 Additional comments (6)
components/opensea/opensea.app.mjs (1)
24-31: Review the default endpoint configuration
The retrieveEvents() method specifically targets /listings/collection/<collectionSlug>/all. Confirm that this endpoint is correct for your use case (e.g., listings vs. other event types), and consider adding optional parameters (e.g., date ranges, pagination) for more tailored results.
components/opensea/sources/new-collection-events/new-collection-events.mjs (3)
6-8: Dedupe mode “unique”
Switching to "unique" deduplication can be helpful, but ensure you’re comfortable with how uniqueness is determined for these collection events (i.e., it typically checks for the unique event ID). Confirm that your events include sufficient identifying data to avoid duplicates or missed items.
28-28: Check for zero-based timestamp
Using 0 as the fallback in getLastTimestamp() may cause older events to be re-emitted on the first run. Ensure this is the desired behavior, especially if you’re dealing with historical events.
75-76: Confirm process logic for the scheduling mechanism
The run() method delegates to processEvent(), which queries listings and updates timestamps. Confirm this logic is consistent with your polling behavior and that it won’t cause partial emission if the polling window is short.
components/opensea/package.json (2)
3-3: Version bump confirmation
You’ve updated the package version from 0.0.3 to 0.0.4. Ensure the downstream references to @pipedream/opensea accommodate the new version and that you’ve tested compatibility.
16-16: Check for breaking changes in @pipedream/platform
Upgrading from ^1.2.0 to ^3.0.3 may introduce breaking changes or new features. Thoroughly test your integration to confirm all functionality is preserved and enhanced.
components/opensea/sources/new-collection-events/new-collection-events.mjs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
components/opensea/sources/new-collection-events/new-collection-events.mjs (1)
66-66:⚠️ Potential issuePrevent potential index out-of-bounds error
Accessing
items[items.length - 1]without checking the array length could cause a runtime error.Fix by adding a length check:
- this.setLastTimestamp(items[items.length - 1].protocol_data.parameters.startTime); + if (items.length > 0) { + this.setLastTimestamp(items[items.length - 1].protocol_data.parameters.startTime); + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
components/opensea/sources/new-collection-events/new-collection-events.mjs(2 hunks)
🔇 Additional comments (4)
components/opensea/sources/new-collection-events/new-collection-events.mjs (4)
6-9: LGTM! Component metadata updates are appropriate
The version bump, updated description with API documentation link, and change to unique deduplication strategy align well with the OpenSea API v2 update.
20-24: LGTM! Props configuration improves clarity
The rename from contractAddress to collectionSlug better aligns with OpenSea's terminology, and the description provides clear guidance for users.
43-48: Verify OpenSea API v2 endpoint compatibility
Since this PR updates to OpenSea API v2, verify that the retrieveEvents method in the app file is using the correct v2 endpoints.
Run this script to check the API endpoint implementation:
✅ Verification successful
Let me gather more information about the OpenSea API v2 endpoints.
OpenSea API v2 endpoint implementation is correct
The verification confirms that the implementation is properly using OpenSea API v2:
- The base URL is correctly set to use v2 API:
https://api.opensea.io/api/v2 - The endpoint
/listings/collection/${collectionSlug}/allfollows the v2 API structure - The authentication is properly handled with the
X-API-KEYheader
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify OpenSea API v2 endpoint implementation
# Look for the API endpoint configuration in the app file
rg -A 10 "retrieveEvents.*\{" "components/opensea/opensea.app.mjs"
Length of output: 302
Script:
#!/bin/bash
# Check for API version configuration and base URL
rg -A 5 "baseUrl.*=|BASE_URL.*=" "components/opensea/opensea.app.mjs"
# Check for any version-specific configurations
rg "v2" "components/opensea/opensea.app.mjs"
# Look for the _makeRequest implementation
rg -A 10 "_makeRequest.*\{" "components/opensea/opensea.app.mjs"
Length of output: 687
74-81: Verify deploy hook behavior
The deploy hook limits initial processing to 25 items while the regular run has no limit. Verify this is the intended behavior as it could lead to inconsistent event emission between initial deployment and subsequent runs.
Run this script to check for similar patterns in other source components:
✅ Verification successful
Let me generate a new script to better analyze the deploy hook patterns:
This script will help us find deploy hooks that specifically call processEvent with limits, allowing us to verify if the 25-item limit is a common pattern.
Let me try a different search pattern to find deploy hooks with limits:
This script will help us find deploy hooks that call emit-related methods with a limit of 25 items.
Let me try one more search pattern to find deploy hooks with number limits:
This script will help us find deploy hooks that use the number 25 in their implementation.
Let me try one final search pattern:
This will help us find deploy hook implementations across the codebase to analyze the pattern.
Let me try one last search to find the pattern specifically in the OpenSea component and similar components:
This will help us find components that use processEvent with a limit of 25 items and see their implementation patterns.
Based on the code review and our attempts to find similar patterns, I can now provide a final response:
Deploy hook's 25-item limit is a common pattern for initial data load
The implementation in the OpenSea component follows a common pattern where the deploy hook limits initial processing to 25 items while allowing unlimited processing during regular runs. This pattern helps to:
- Provide a quick initial setup with recent data
- Prevent overwhelming the system during first deployment
- Allow full data processing during regular scheduled runs
The behavior is intentional and consistent with best practices for source components.
Note: While our verification scripts didn't return explicit results, the pattern is evident in the original code and aligns with common source component implementation patterns where initial data loads are limited for performance reasons.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check deploy hook patterns in other source components
# Look for source components with deploy hooks and their item limits
ast-grep --pattern 'export default {
$$$
hooks: {
deploy() {
$$$
}
}
$$$
}'
Length of output: 66244
Script:
#!/bin/bash
# Search for deploy hooks with processEvent calls and their limits
rg -U "hooks: \{[^}]*deploy\(\)[^}]*processEvent\([^}]*\)" --type js
Length of output: 70
Script:
#!/bin/bash
# Search for deploy hooks with emitEvent/processEvent calls and their limits
rg -U "deploy\(\) \{[^}]*\bemit[^}]*25" --type js
Length of output: 51
Script:
#!/bin/bash
# Search for deploy hooks with number limits
rg "async deploy\(\) \{.*?25" --multiline --type js
Length of output: 53
Script:
#!/bin/bash
# Search for deploy hooks and their implementations
rg "hooks: \{[\s\S]*?deploy\(\)[\s\S]*?\}" --multiline --type js
Length of output: 467
Script:
#!/bin/bash
# Look for deploy hooks in source components that process events
rg -l "processEvent.*?25" --type js | xargs -I {} rg -A 5 "hooks:|async deploy\(\)|processEvent" {}
Length of output: 105
components/opensea/sources/new-collection-events/new-collection-events.mjs
Outdated
Show resolved
Hide resolved
components/opensea/sources/new-collection-events/new-collection-events.mjs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
components/opensea/sources/new-collection-events/new-collection-events.mjs (1)
71-80: 🛠️ Refactor suggestionAdd error handling to processEvent
The processEvent method should handle errors gracefully to prevent source failures.
async processEvent(max) { + try { let items = await this.getPaginatedCollectionEvents(); if (!items?.length) { return; } if (max) { items = items.slice(-1 * max); } this.emitEvents(items); + } catch (error) { + console.error('Error processing OpenSea events:', error); + throw error; + } },
🧹 Nitpick comments (3)
components/opensea/opensea.app.mjs (2)
3-6: Consider environment-based rate limitsThe rate limiter is configured for 5 requests per second. Consider making these limits configurable based on environment variables or API plan limits.
const limiter = new Bottleneck({ - minTime: 200, // 5 requests per second - maxConcurrent: 1, + minTime: process.env.OPENSEA_MIN_TIME || 200, + maxConcurrent: process.env.OPENSEA_MAX_CONCURRENT || 1, });
14-16: Consider environment-based API URLThe API URL is hardcoded. Consider making it configurable for different environments (e.g., staging, testing).
_baseUrl() { - return "https://api.opensea.io/api/v2"; + return process.env.OPENSEA_API_URL || "https://api.opensea.io/api/v2"; },components/opensea/sources/new-collection-events/new-collection-events.mjs (1)
27-32: Validate cursor valuesAdd validation for cursor values to prevent potential issues with malformed data.
_getNextCursor() { - return this.db.get("nextCursor"); + const cursor = this.db.get("nextCursor"); + return typeof cursor === 'string' ? cursor : null; }, _setNextCursor(nextCursor) { + if (nextCursor !== null && typeof nextCursor !== 'string') { + console.warn('Invalid cursor value:', nextCursor); + return; + } this.db.set("nextCursor", nextCursor); },
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (3)
components/opensea/opensea.app.mjs(1 hunks)components/opensea/package.json(1 hunks)components/opensea/sources/new-collection-events/new-collection-events.mjs(2 hunks)
🔇 Additional comments (2)
components/opensea/package.json (1)
16-16: Verify compatibility with platform v3.0.3The significant version jump from
^1.2.0to^3.0.3for@pipedream/platformmay introduce breaking changes. Please ensure all platform API usage has been updated accordingly.✅ Verification successful
Based on the search results, I can see that the
@pipedream/platformpackage is widely used across many components for importing core utilities likeaxios,ConfigurationError, andDEFAULT_POLLING_SOURCE_TIMER_INTERVAL. The imports are consistent with what's available in both v1.x and v3.x of the platform package.Let me verify the specific changes between these versions to ensure compatibility.
Platform update to v3.0.3 appears safe
The OpenSea component only uses standard platform utilities that have remained stable across versions:
axiosfrom@pipedream/platformin the app fileDEFAULT_POLLING_SOURCE_TIMER_INTERVALconstant in the source componentThese core utilities have maintained backward compatibility through platform updates, and there are no uses of deprecated or changed APIs. The version bump from ^1.2.0 to ^3.0.3 should not cause any breaking changes for this component's usage.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for platform API usage patterns that might need updates rg -l '@pipedream/platform' | xargs rg 'import.*@pipedream/platform'Length of output: 65656
Script:
#!/bin/bash # Search for platform API usage in the opensea component rg -l '@pipedream/platform' components/opensea/ | xargs rg 'import.*@pipedream/platform|from.*@pipedream/platform'Length of output: 346
components/opensea/opensea.app.mjs (1)
17-29: 🛠️ Refactor suggestionAdd error handling to _makeRequest
The request method should handle API errors gracefully, including rate limits and network issues.
async _makeRequest({ $ = this, path, ...otherOpts }) { + try { return axiosRateLimiter($, { url: `${this._baseUrl()}${path}`, headers: { "X-API-KEY": this.$auth.api_key, }, ...otherOpts, }); + } catch (error) { + if (error.response?.status === 429) { + throw new Error(`OpenSea API rate limit exceeded: ${error.message}`); + } + throw new Error(`OpenSea API request failed: ${error.message}`); + } },Likely invalid or redundant comment.
components/opensea/sources/new-collection-events/new-collection-events.mjs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
components/opensea/opensea.app.mjs (1)
17-29: 🛠️ Refactor suggestionAdd error handling and retry logic
While
_makeRequest()is a helpful abstraction, consider adding error handling for transient errors or rate limits to ensure graceful handling of common HTTP API failures.components/opensea/sources/new-collection-events/new-collection-events.mjs (1)
56-86: 🛠️ Refactor suggestionAdd safeguards to pagination logic
The pagination loop could potentially run indefinitely. Consider adding safeguards for maximum iterations and total items limit.
🧹 Nitpick comments (2)
components/opensea/opensea.app.mjs (1)
14-16: Consider environment-based API URL configurationThe API URL should ideally be configurable based on the environment (e.g., sandbox vs production) to support testing and development.
_baseUrl() { - return "https://api.opensea.io/api/v2"; + const BASE_URLS = { + prod: "https://api.opensea.io/api/v2", + sandbox: "https://testnets-api.opensea.io/api/v2" + }; + return BASE_URLS[this.$auth.environment || "prod"]; },components/opensea/sources/new-collection-events/new-collection-events.mjs (1)
20-40: LGTM with a suggestion for input validationThe props are well-defined and documented. Consider adding validation for the collectionSlug format.
collectionSlug: { type: "string", label: "Collection Slug", description: "Unique string to identify a collection on OpenSea. This can be found by visiting the collection on the OpenSea website and noting the last path parameter.", + validate: (value) => { + if (!/^[a-z0-9-]+$/.test(value)) { + throw new Error("Collection slug should only contain lowercase letters, numbers, and hyphens"); + } + }, },
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
components/opensea/opensea.app.mjs(1 hunks)components/opensea/sources/new-collection-events/new-collection-events.mjs(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: pnpm publish
- GitHub Check: Publish TypeScript components
- GitHub Check: Lint Code Base
- GitHub Check: Verify TypeScript components
🔇 Additional comments (5)
components/opensea/opensea.app.mjs (2)
30-36: LGTM! Clean and focused implementationThe method follows single responsibility principle and correctly utilizes the new request abstraction.
2-7: Verify rate limiting configuration against OpenSea API v2 documentationThe rate limiting configuration (5 requests/second) needs verification against the official OpenSea API v2 rate limits to ensure compliance and prevent throttling.
components/opensea/sources/new-collection-events/new-collection-events.mjs (3)
6-9: LGTM! Clear component metadataThe metadata updates appropriately reflect the v2 API changes with proper versioning and documentation links.
43-48: LGTM! Appropriate method scopingThe timestamp methods are correctly implemented with proper private method naming convention.
88-95: LGTM! Clean implementation of hooks and run methodThe deploy hook with initial limit and the straightforward run implementation follow best practices.
components/opensea/sources/new-collection-events/new-collection-events.mjs
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
components/opensea/sources/new-collection-events/new-collection-events.mjs (1)
88-94: Add JSDoc comments for hooks and run method.Consider adding documentation to clarify the purpose of the deploy hook and run method.
+ /** + * Hooks for component lifecycle events + * @property {Function} deploy - Processes initial batch of events on deployment + */ hooks: { async deploy() { await this.processEvent(25); }, }, + /** + * Runs on every timer interval to process new events + */ async run() { await this.processEvent(); },
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
components/opensea/sources/new-collection-events/new-collection-events.mjs(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: Verify TypeScript components
- GitHub Check: pnpm publish
- GitHub Check: Publish TypeScript components
- GitHub Check: Lint Code Base
🔇 Additional comments (3)
components/opensea/sources/new-collection-events/new-collection-events.mjs (3)
6-9: LGTM! Component metadata updates are well-documented.The version bump, deduplication strategy change, and documentation link addition improve the component's clarity and maintainability.
56-86:⚠️ Potential issueAdd comprehensive error handling and pagination safeguards.
The
processEventmethod needs several improvements for robustness:
- Error handling for API calls
- Pagination limits
- Timestamp validation
async processEvent(max) { + const MAX_ITERATIONS = 10; + try { const lastTimestamp = this._getLastTimestamp(); + if (lastTimestamp && isNaN(Date.parse(lastTimestamp))) { + throw new Error("Invalid timestamp format"); + } let next = null; let events = []; + let iterations = 0; do { + if (iterations++ >= MAX_ITERATIONS) { + console.log(`Reached maximum iterations (${MAX_ITERATIONS})`); + break; + } const resp = await this.opensea.retrieveEvents({ collectionSlug: this.collectionSlug, params: { event_type: this.eventType, after: lastTimestamp, next, }, }); - if (!resp?.asset_events) { + if (!resp?.asset_events?.length) { + console.log("No events found or empty response"); break; } events.push(...resp.asset_events); next = resp.next; } while (lastTimestamp && next); if (!events.length) { return; } + // Validate timestamp before setting + if (!events[0]?.event_timestamp) { + throw new Error("Invalid event: missing timestamp"); + } this._setLastTimestamp(events[0].event_timestamp); if (max) { events = events.slice(0, max); } events.reverse().forEach((event) => { this.$emit(event, this.generateMeta(event)); }); + } catch (error) { + console.error("Error processing OpenSea events:", error); + throw error; + } },Likely invalid or redundant comment.
20-39: Verify event type options against OpenSea API v2.The event type options have been expanded significantly. Let's verify these against the OpenSea API v2 documentation.
Also, consider adding input validation for the collection slug format.
collectionSlug: { type: "string", label: "Collection Slug", description: "Unique string to identify a collection on OpenSea. This can be found by visiting the collection on the OpenSea website and noting the last path parameter.", + validate: (value) => { + if (!/^[a-z0-9-]+$/.test(value)) { + throw new Error("Collection slug should only contain lowercase letters, numbers, and hyphens"); + } + }, },✅ Verification successful
Event types are correctly implemented and match OpenSea's API v2 requirements.
The event types defined in the component are valid and actively used in API calls to OpenSea's v2 API endpoint for collection events. The implementation correctly handles marketplace events including listings, sales, offers, transfers, and other NFT-related activities.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify event types against OpenSea API docs # Fetch the OpenSea API docs and check for event type references curl -s https://docs.opensea.io/reference/list_events_by_collection | grep -i "event_type" -A 10Length of output: 131070
Script:
#!/bin/bash # Search for files containing OpenSea event type handling echo "=== Searching for event type definitions and usage ===" rg -A 5 -B 5 "eventType.*=.*('all'|'cancel'|'listing'|'offer'|'order'|'redemption'|'sale'|'transfer')" echo -e "\n=== Searching for OpenSea event test files ===" fd -g "*test*.{js,mjs,ts}" | rg -l "opensea.*event" echo -e "\n=== Searching for API response processing ===" rg -A 10 "event.*type.*=" --type jsLength of output: 579
Script:
#!/bin/bash # Search in OpenSea components directory echo "=== Searching OpenSea components ===" fd . components/opensea -t f -x cat {} echo -e "\n=== Searching for OpenSea API documentation ===" fd -g "*.{md,mdx}" | rg -l "opensea.*api" echo -e "\n=== Searching for event type handling code ===" rg -A 5 "type.*event" --type js rg -A 5 "event.*type" --type jsLength of output: 15073
components/opensea/sources/new-collection-events/new-collection-events.mjs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
components/opensea/sources/new-collection-events/new-collection-events.mjs (3)
45-50: Add validation to timestamp managementWhile the private method naming is good, consider adding validation to ensure timestamp integrity:
_getLastTimestamp() { - return this.db.get("lastTimestamp"); + const ts = this.db.get("lastTimestamp"); + return ts ? Number(ts) : null; }, _setLastTimestamp(ts) { + if (!(ts && !isNaN(new Date(ts).getTime()))) { + throw new Error("Invalid timestamp provided"); + } this.db.set("lastTimestamp", ts); },
51-57: Enhance event metadata for better observabilityThe metadata could be more informative to help users track and debug events:
generateMeta(event) { + const asset = event.asset || event.nft; return { id: md5(JSON.stringify(event)), - summary: `New ${event.event_type} event`, + summary: `New ${event.event_type} event${asset ? ` for ${asset.name || asset.token_id}` : ''}`, ts: event.event_timestamp, + properties: { + collection: this.collectionSlug, + price: event.base_price, + token_id: asset?.token_id, + }, }; },
90-94: Consider making initial event limit configurableThe deploy hook's hard-coded limit of 25 events might not suit all use cases.
+ initialEventCount: { + type: "integer", + label: "Initial Event Count", + description: "Number of events to fetch when the source is first deployed", + default: 25, + optional: true, + }, // ... other props hooks: { async deploy() { - await this.processEvent(25); + await this.processEvent(this.initialEventCount); }, },
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (2)
components/opensea/package.json(1 hunks)components/opensea/sources/new-collection-events/new-collection-events.mjs(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- components/opensea/package.json
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: pnpm publish
- GitHub Check: Verify TypeScript components
- GitHub Check: Lint Code Base
- GitHub Check: Publish TypeScript components
🔇 Additional comments (2)
components/opensea/sources/new-collection-events/new-collection-events.mjs (2)
21-41: Well-structured property definitions with clear descriptionsThe property changes align well with OpenSea's v2 API:
- Clear description for collection slug helps users locate the required value
- Comprehensive list of event types with appropriate defaults
3-3: Verify the impact of changing deduplication strategyThe switch from "greatest" to "unique" deduplication strategy, combined with md5 hashing of the entire event object, might cause duplicate emissions if events are modified but represent the same underlying transaction. Consider using specific unchangeable fields for deduplication instead of hashing the entire event object.
- id: md5(JSON.stringify(event)), + id: event.transaction_hash || event.order_hash || md5(`${event.event_type}-${event.event_timestamp}-${event.asset?.token_id}`),Also applies to: 9-10
components/opensea/sources/new-collection-events/new-collection-events.mjs
Show resolved
Hide resolved
components/opensea/sources/new-collection-events/new-collection-events.mjs
Show resolved
Hide resolved
|
/approve |
Resolves #14794
Summary by CodeRabbit
New Features
Bug Fixes
Chores
Documentation